Fine-grained access control

Access management in an application often requires a hierarchy to effectively manage user access to different resources. This hierarchy is typically based on roles and their connections to resources, as well as their position within the hierarchy itself.

For instance, a user with an 'Admin' role might have access to all resources, while a 'Manager' might only have access to resources within their department. This hierarchical structure allows for fine-grained control over who can access what, ensuring security and efficiency.

Moreover, Relationship-Based Access Control (ReBAC) adds another layer of complexity and flexibility to this model. ReBAC allows permissions to be granted based on relationships between subjects and objects. For example, a user might be granted access to a document because they are part of the same project team as the document creator. This allows for more dynamic and context-aware access control, further enhancing the security and adaptability of the system.

Token issuer

Akkess is a token issuer. When a user is authenticated, the user is issued an access token that can be used to access services. Akkess is responsible to issue an IAM token - this token is typically used for accessing microservices and give needed information to the microservice to make access control decisions.

• Should I allow the caller to access the wanted resource?
• Who is the caller?
• To which tenant does the caller belong?

info

Note that Akkess does not authenticate the end user.
Doing that is the responsibility of an Identity Provider (IdP), for example Google, Facebook, or a custom IdP.

See identity abstraction for additional details.

Example of issuing a token flow

Authorization steps

When accessing an API, the service will check that the caller has the right to access said API and also to apply any data access restrictions.
The checks is applied in the following order:

1. The service receives a request with an Akkess IAM token
2. The service validates the token signature
3. The service validates that the token is not expired
4. The service validates that the token is not revoked
5. The service evaluates the effective permissions by cross-referencing the caller's access references with the configured roles for the application
6. The service apply any configured row filtering for data access
7. The service apply any configured attribute filtering for data access

In order to be as autonomous as possible, the service will need at least to cache the JWK from Akkess to be able to validate the token signature. Additionally, the service will likely need to cache the role and permission configuration for any applications that is expected to call the service. This information is needed for dynamically evaluate the effective permissions of the caller.

Endpoint access

Access to an endpoint is controlled by the service declaring that one or more permissions is needed in order to access said endpoint.
If the caller has the needed permission(s) via one of its access references then the call is accepted and may proceed to the next stage.

Data access

Row filtering

Row filtering conditions can be used control which entries that are accessible in the underlying data source. In essence this will either include or exclude entire entries and as such may affect pagination when reading collections. Filtering can be applied via conditions on said data on the row itself or via rules that configure relational and hierarchical data access.

Attribute filtering

Attribute filtering can be used to exclude parts of an entity when returning data to the caller. It can be applied to hide sensitive data for certain roles or exclude partial data from arrays.

Relational and hierarchical data access

Access to data may also be modeled by via the referenced resource for a given access reference.
The resource reference can be used as a way of signaling that the caller has access to this specific resource, but it can also be used in combination with 'rules' to allow for hierarchical data access.

For our services we rely on access references and node hierarchies to model hierarchical access control and our rules allow for configuration options such as:

• tenant wide access
• access to specific resource
• access to ancestors of referenced resource
• access to descendants of referenced resource