Skip to content
Hantera Developer Portal Developer Portal

Access Control

Once authenticated, your session will have access to resources. The resources available to the session are determined by the user or client’s permissions, combined with the scopes granted during sign-in (see Authentication). Access is structured in a cascading tree where each resource may have multiple permissions.

Access Control Entry (ACE)

Throughout this documentation, you will encounter the term Access Control Entry (ACE). An ACE consists of a resource path and optional permission. Here are some examples:

actors:*
  • Authorizes full access to all actor types and actors. All permissions are granted.
actors/order:*
  • Authorizes full access to all messages for all order actors.
actors/order:applyCommands
  • Authorizes the applyCommands message for order actors.
actors/order/b3cf0d63-6ad7-4923-8060-90fb6935954d
  • Authorizes all messages for the order actor with ID “b3cf0d63-6ad7-4923-8060-90fb6935954d”.
actors/order/b3cf0d63-6ad7-4923-8060-90fb6935954d:applyCommands
  • Authorizes the message type applyCommands for the order actor with ID “b3cf0d63-6ad7-4923-8060-90fb6935954d”.

Cascading Access

Access is cascading, meaning any permission applied at a higher level is inherited by child resources. A resource access with no specific permissions implicitly grants all available permissions on that resource.

Nested Permissions

Some permissions can be nested. For example, actors/order:applyCommands authorizes the applyCommands message, but this message also supports nested permissions for each command. So actors/order:applyCommands:setNotes only authorizes the setNotes command, restricting all other commands. actors/order:applyCommands gives full access to the message including all commands.

Roles and Access Control Lists (ACL)

To simplify management among many users and clients, roles can be created and assigned. Each role has an Access Control List (ACL) containing multiple ACEs that will be granted to any identity with that role.

Users and clients (identities) may also have directly applied ACEs. This is particularly useful for clients used for integration purposes where there is no overlap between multiple clients.

Example Configuration

An identity or role will generally have many ACEs to configure access. Here’s an example configuration that allows an identity to create new orders and query for order orderIds and orderNumber in the graph:

actors/order:create
graph/order:orderId
graph/order:orderNumber

Attribute-Based Access Control (ABAC)

For advanced scenarios, Attribute-Based Access Control (ABAC) can be used to grant access to data. ABAC is useful, for example, when you have users who should only see data for a specific market or country, or a customer account that should only access its own data.

Attributes can be tied to ACEs, making the resource access only viable if the identity or role has a matching value of those attributes with the actor or graph node.

The available attributes are per actor type, so refer to Actor Types for detailed information on available access attributes. The graph also supports attribute access, and generally, all fields in the graph are available.

Practical Example

Let’s say you have a user who should only see orders in channel “EU”.

  1. Add the access attribute channelKey="EU" to the user.

  2. Add the following ACL to the user:

    channelKey@actors/order:*
    channelKey@graph/order:*
    channelKey@graph/delivery:*
    channelKey@graph/orderLine:*
    channelKey@graph/invoice:*
    channelKey@graph/payment:*
    channelKey@graph/orderJournalEntry:*