Domain modeling

In Akkess, we use the concepts of actors and nodes to model hierarchical access control.

Actors represent the subjects, such as users, cars, devices, items etc., while nodes represents the nodes in a tree with relationships, such as resources, departments, or projects.

By defining relationships between actors and nodes, you can create a flexible and powerful access control system that adapts to your specific requirements. They also have flexible data models which allow for storing your business data in closely to these entities.
Actors and nodes always belong to a tenant. This means that any access references are always scoped to said tenant.

Node hierarchy

Nodes are modeled in a tree structure where a node could either be a root node or a child node of another node. This structure is often referred to as a Directed Acyclic Graph (DAG).

Nodes offer a flexible way to model and organize your data. From simple organization hierarchies to more domain specific structures which reflects your business needs.

Example:

Access references

An actor can have access references to resources. It can be a reference to a node, another actor, or something else. The access reference is always combined with an access level - a role. Based on the role's access level, the actor can perform certain actions on the resource the access reference points to.

Four kind of references are supported:

• No resource defined - The actor has the role for the whole tenant and not for a specific resource. For example an end user with the role 'Admin' has the role for the whole system.
• Node - The actor has the role for a node. For example an end user with the role 'Manager' has the role for a department node.
• Actor - The actor has the role for another actor. For example an end user with the role 'Carer' has the role for another end user.
• Custom resource - The actor has the role for a custom resource. For example a user with the role 'Driver' has the role for a VehicleIdentificationNumber. Custom resources are always a combination of type and value.

The access references are part of the Akkess token and is detailed under the ars attribute. This means that each service could evaluate the caller's access level just using the token in combination with role-permission-configuration.

Example of node references

Example of actor and custom references

Example of ars in a token

Custom resources are always a combination of type and value separated by an equal sign. For example VIN=4Y1SL65848Z411439 where VIN (Vehicle Identification Number) is the type and 4Y1SL65848Z411439 is the actual identity.

  "ars": [
    {
      "r": ["EMPLOYEE"],
      "n": ["63c65dee83abd41be9f61108"]
    },
    {
      "r": ["MANAGER"],
      "n": ["63c65dee83abd41be9f61109", "63c65dee83abd41be9f61110"]
    },
    {
      "r": ["CARER"],
      "a": ["63c65dee83abd41be9f61111"]
    },
    {
      "r": ["DRIVER"],
      "c": ["VIN=4Y1SL65848Z411439"]
    }
  ]  

Model your domain

By defining and grouping your variants of end users using different types of actors, along with nodes to represent your structures and finally roles and access references to define the access levels, you can create a powerful and flexible access control system that adapts to your specific business requirements.

The chosen names for these types can reflect your domain and nomenclature to make it easier for your team to understand and work with the system and also for your end users.

Your model and data can also be visualized and browsed via the Akkess IAM Tenant console.