Domains
Authorization domains are central to the Axiomatics' methodology for defining authorization policies. Essentially, they are logical containers used to organize and manage all the components necessary in evaluating access requests and returning appropriate authorization responses.
A domain groups the following data:
- Policies: The set of rules, written in ALFA, that define access logic (who can do what under which conditions).
- Attributes: The vocabulary of the authorization system (user roles, resource sensitivity, action IDs, etc).
- Attribute connectors: The components that link the domain to external data sources, such as a database or LDAP directory, to dynamically fetch attribute values at the time of a request.
- Attribute cache: A cache used to store attribute values retrieved from attribute connectors, aiming to enhance performance.
- Partial evaluation threshold: An indicator specifying the minimum number of individual requests a multiple-decision request must contain before the authorization engine attempts to optimize it.
Interface
Upon accessing the Domains section, a comprehensive list of all existing domains displays. This interface provides key information at a glance, including:
| Description | |
|---|---|
| Name | The unique identifier for each domain, serving as a readily identifiable label for its purpose and usage. For instance, abc_example_com can be the domain name of a corporation named ABC Corp. |
| Description | A brief overview of the domain's purpose or scope. |
| Created by | The user who created the domain. |
| Attribute connectors | The attribute connectors added to the domain. Attribute connectors are required when attributes used in a policy need to get their values from an external source. TIP: When clicked, the attribute connectors icon lists the attribute connectors by their type, the provided attribute(s), and the applied cache configuration for each provided attribute. NOTE: The authorization engine is only aware of the two cache configuration values, not the cache profile itself, because the latter is not part of the domain definition. |
| API URL | Provides a direct link to the API endpoint associated with the domain, which can be copied for use in integration tasks. |
Additionally, the following features are available in this section to help you manage your domains effectively:
-
Filter: Use the filter field to refine the list and narrow down the displayed domains. You can enter a domain name, a part of a description, or a 'created by' entry.
noteThis is a dynamic search field and returns relevant results as you type.
-
Sorting: Sort the contents of the list by column values by clicking the header of the column whose contents you want to sort by.
-
Column selection: Use the column selector above the list to choose which columns display. The Name and actions columns cannot be hidden. Your selection is remembered for this list in your browser, but it is not shared with other browsers, devices, or users. Use the reset option to return to the default columns.
-
Actionable links: The API URL column provides a quick way to copy the API link associated with a domain, facilitating easier integration and management of external systems.
Edit a domain
A core function of this interface is providing you with the ability to edit your existing domains. To modify a domain:
-
Click the domain name itself, or click the three dots on the right side of the row and choose Edit.
-
Make your preferred changes within the Edit domain window.
Read the Add a new domain section for details about the available fields.
noteThe data displayed for Attribute connectors and Policy entry points is not synchronized with the domain data. Instead, it reflects the current state of the respective attribute connectors and policies. Read the notice below for details.
-
Click Update.
-
Confirm the update in the dialog that appears. Proceeding brings in the latest policy and attribute connector changes from the project, including changes made by other users since the last domain update.
Click Yes, update to proceed, or Cancel to keep the domain unchanged.
Once the update completes, a confirmation message appears. If the update fails, an error message displays so you can try again.
Changes to the domain's data (such as policies or attributes) are only propagated to the configuration file after the domain has been edited and updated. Even a minor change, like updating the domain's description, qualifies as an update and refreshes all domain data. Once updated, a new domain version replaces the previous one in the interface, and the new configuration file becomes available for the authorization engine to fetch.
Domain history
Authorization Hub keeps a history of previous instances for each domain, allowing you to review changes (what, when, and by whom) and roll back to an earlier instance if needed.
To view a domain's history:
- Hover the domain's row.
- Click the three dots.
- Choose Rollback.
This opens the Rollback domain dialog that lists the domain's instances, ordered newest first, with the current instance labeled CURRENT. Each instance shows its description, who created it, and when. Click View configuration on any instance, including the current one, to expand its configuration inline without leaving the list. You can scroll through the full list and browse freely. Closing the dialog without rolling back makes no changes.
Access to domain history and rollback depends on your project role:
| Domain viewer | Project viewer | Project editor | Project admin | |
|---|---|---|---|---|
| View domain history | ❌ | ❌ | ✔️ | ✔️ |
| Roll back a domain | ❌ | ❌ | ✔️ | ✔️ |
Read the Project roles section for details on each role.
Rolling back a domain
Select the instance you want to roll back to using its radio button and click Rollback.
You cannot select the current instance. Additionally, because a rollback re-uses the domain's original instance, the same instance can appear again as an older entry in the list. These entries are also disabled.
Rolling back re-creates the selected instance as the domain's current state without affecting any other project artifacts (attributes, attribute connectors, policies, or cache configuration). Click Cancel to close the dialog without making any changes.
If the rollback succeeds, the domain is fully restored to the selected instance. If it fails, you'll see an error and the domain remains on its current instance with no changes applied.
Entries for other instances remain selectable, even if their configuration is identical to the current one.
A successful rollback is recorded in the activity feed as an update, showing who performed the rollback, the domain name, and when it took place.
Domain configuration file
The data of the authorization domain is stored in a domain configuration file. This file contains a collection of policies and settings, including attribute connectors and cache configurations. Authorization Hub supports authorization domain version 2.1.
To understand the structure of the domain file and see a detailed analysis of its sections, read the Authorization domain file analysis section of the Authorization Domain Manager (ADM) documentationOpens in a new tab.
In order for the authorization engine to fetch the domain configuration file, you have to utilize the API URL. See the Interface and API reference sections for details.
When you create an authorization domain using a defined policy as the entry point, the domain's attribute section is populated only with the attributes actively used within that specific domain. These attributes originate from three sources:
- the
attribute-dictionary.alfafile bundled with your policy - the attribute definitions from the attribute connector configurations (including both provided and key attributes)
- the attributes defined within the ALFA policies themselves
API reference
Domains are created and rolled back through the Hub service, and stored and served by the domain manager service. The Authorization Hub REST API interactive documentation is available in the Swagger UI API:
| Service | Used for | URL |
|---|---|---|
| Hub service | Composing and rolling back domains (Domains definition) | http(s)://<authorization-hub-url>/api/hub-service/swagger-ui/index.html |
| Domain manager | Reading domains and their history | http(s)://<authorization-hub-url>/api/adm-service/swagger-ui/index.html |
Read the Domains endpoint reference for descriptions of the endpoints, the compose request, and the errors.
Key parameters
When handling domains through the API, use the following:
| Parameter | Value | Notes |
|---|---|---|
namespace | Your project ID | Used in the path of the domain manager endpoints. You can retrieve the namespace through: - the GET /api/projects endpoint- the Authorization Hub interface after opening the project and extracting it from the URL. For example, in https://sample.hub.domain/projects/e00f12c8-8f3a-40ac-81a7-5a762abc7288/dashboard, the namespace is e00f12c8-8f3a-40ac-81a7-5a762abc7288. |
X-Project-Id header | Your project ID | Required when composing or rolling back a domain through the Hub service. |
domainName | The domain name | Used in the path when composing or rolling back a domain. |
Authenticate the authorization engine
The authorization engine fetches the domain from its API URL (https://<authorization-hub-url>/api/adm/namespaces/<project-id>/names/<domain-name>/domain). It must authenticate with a Bearer token, like any other API client. Create a client for the engine, add it to the project with the Domain viewer role, which is enough to read domains, and configure the engine to use it. Read Client management.