Skip to main content

Access management

Access management is a critical component of information security that involves ensuring only authorized users have access to specific resources, systems or information. It encompasses various models and techniques designed to control and monitor who can access information within an organization, under what conditions, and ensuring that access levels are maintained and updated in line with user roles and responsibilities.

Variants of access management

  • Role-Based Access Control (RBAC)

    • Assigns users to roles based on their job functions within the organization
    • Access permissions are then granted to roles rather than individual users, simplifying the administration of access rights as users' roles change
  • Relationship-Based Access Control (ReBAC)

    • Extends RBAC by considering the relationships between entities (users, resources, etc.) to make access decisions
    • Useful in contexts where access needs to be dynamic and based on specific relationships, such as social networks or collaborative platforms
  • Attribute-Based Access Control (ABAC)

    • Uses policies that evaluate attributes (or characteristics) of users, resources, and the environment to make access decisions
    • Allows for more dynamic and context-sensitive access control, capable of handling complex scenarios with fine-grained precision
  • Fine-Grained Access Control (FGA)

    • Ability to provide highly detailed access control, down to the level of individual records or data fields
    • Often implemented using policies to ensure that users have access only to the specific data they need for their tasks, enhancing security and privacy protection
    • Commonly used in applications where data sensitivity and privacy are paramount, such as healthcare, finance, and government

Access management, through the use of these models, ensures that the right users have the right access to the right resources at the right times, and for the right reasons, thereby protecting sensitive information from unauthorized access and breaches. See fine-grained access control page for additional details on how Akkess applies this concept for access control.

Role and permissions

Akkess provides a powerful and flexible role and permission management system. The system is designed to be used for fine-grained access control and is based on the concepts of roles and permissions.

We practice "eat your own dog food" and use Akkess for managing accesses to Akkess API. For examples of service and permission definitions you can take a look on the powerful and flexible actor and node APIs. Each service has its own set of permissions defined. Our tools like Akkess IAM Console is built on top of the Akkess Node and Actor API and uses the same permissions as any other service.

Role example

Service definition

Each service in the system defines its capabilities by declaring a ´service definition´.
This definition is used as a schematic when an administrator of an application configures its roles and their respective permissions.

Permission definition

A Permission definition is a definition of a permission that a service can provide. The permission definition is used to define what the permission is and what it can be used for.

Example of a permission definition could be "Read document" or "Write document".

Permission definition

Entity definition (optional)

An Entity definition is a definition of an entity that can be used in a permission. An entity is a thing that the service manage. Like a document, a user, a car etc.

An entity definition is for implementing attribute projection. For example only return certain fields of the entity based on the access level. Example only return the 'name' and 'email' if the access level is 'A'.

The entity definition could also define if filtering is supported. For example, only return entities that match a certain filter based on the access level. Example return 'A' if the type is 'X' or 'Z'.

Entity definition

Rule definition (optional)

A Rule definition is a definition of a rule that can be used in a permission. A rule is a thing that the service can evaluate. The rule is very flexible and can be used for many things. For example, evaluate if the user belongs to a specific group or if the user has a specific attribute. Rule definitions is typically used for customized access logic in the service.

The rule definition externalizes the configuration of the access logic from the service. This makes it possible to configure the access logic without changing the service.

Rule definition

Full example

info

Akkess gives the tools for configuring, distributing and evaluate accesses rights when calling akkess services.
The evaluation of a permission in your service must be implemented in your service.

In this example we use a car and its owner, driver, mechanic and external system.
The car is a resource that can be accessed by the owner, driver, mechanic and an external system.

The owner can manage the car, the driver can use the car and the mechanic are employed by a service organization repair the car. The service organization is allowed to manage the car. And the external system is allowed to read some data from the car to build services.

Roles

  • AUTO_MECHANIC - Responsible for manage cars and do repairs
  • OWNER - Owner of a car
  • DRIVER- A user of a car. Assigned by the owner
  • CAR - The actual vehicle
  • EXTERNAL_SERVICE - A 3:d party system that delivers a service for car owners. Like a car traffic monitoring or a parking service.

Permissions

  • READ_ERROR_CODES - Check the health of the car
  • SET_ERROR_CODES - Set the car's error codes
  • LOCK / UNLOCK - Lock or unlock the car
  • SET_MAX_LIMIT - Set max speed limit
  • READ_MAX_LIMIT - Read max speed limit
  • READ_LOCATION - Read where the car is located
  • SET_LOCATION - Set the car's location
  • READ_VIN - Read the Vehicle Identification Number

Access control problem

  1. AUTO_MECHANIC should be able to READ_ERROR_CODES and READ_VIN for all cars connected to the service organization where the mechanic is employed. But the mechanic should not be allowed to for example read the cars location
  2. The OWNER should be able to do everything except READ_ERROR_CODES
  3. The DRIVER should be able to
  • READ_LOCATION
  • READ_VIN
  • READ_MAX_LIMIT
  • LOCK / UNLOCK
  1. The CAR should be able to updates its state - like current location or error codes
  2. The EXTERNAL_SERVICE should for example be able to read the car's location and VIN. This depends on which grants have given to the service by the OWNER

Some questions to ask as a system architect

  1. How do I scale the permissions when new requirements comes?
  2. How do I manage the permissions and roles?
  3. How do I distribute a role access level to the services in a microservice architecture?
  4. How do I authorize the caller?
  5. How do I make sure that the caller only can access the wanted resource?
  6. How do I know who is calling?
  7. How do I know to which organization/tenant the caller belongs?
  8. How can I scale my system with more microservices?
  9. How can I make my microservices autonomous and avoid single-point-of-failure?
  10. How do I mark data belonging to a person and still is compliant to GDPR and other privacy laws?
  11. How do I support different ways of authentications?
  12. How do I support hybrid cloud?
  13. How do can I move towards a zero-trust solution?
  14. How do I trace who did what?
  15. How I keep my time plan and budget 😃?

This rather simple example becomes quickly complex when you add more roles, hierarchies, permissions, relations etc. This is where Akkess comes in. Akkess is a service that helps you manage fine-grained access control in a multi-tenant environment. It is a service that can be used to issue tokens that can be used to access services. The token contains information about the caller and the tenant the caller belongs to. The service can use this information to evaluate the caller's access level and construct a command to its logic and database that only affects or returns allowed data.

Akkess supports RBAC, ReBAC and is even extendable to ABAC.

At a first glance it might look complex and hard to get started - but if you are serious about access control and security you will soon realize that Akkess is a powerful tool that can help you to build a robust and secure system. Access control is a heavy task, and it is important to get it right from start and have a foundation that can scale and be flexible when new requirements come.