Skip to main content
Version: 26.2

Introduction

The Authorization Hub is the central platform for managing Attribute-Based Access Control (ABAC) across your organization. It is the control plane of the Axiomatics Authorization Management Platform: the place where teams define the attributes, attribute connectors, and policies that govern access, and package them into domains that the Access Decision Service (ADS) uses to make runtime decisions. This gives you a single, governed source of authorization logic and enables consistent enforcement of zero-trust security principles throughout the organization.

You work in Authorization Hub through a web interface or its REST API, and teams collaborate in isolated projects with role-based access.

What you can do with Authorization Hub​

  • Define attributes: Build a shared vocabulary of attributes that describe users, resources, actions, and context in the Dictionary.
  • Connect to your data: Configure attribute connectors (LDAP, SQL, Table, HTTP, and JWT, JSON, and XML parsers) to fetch attribute values from your own systems at runtime, and tune performance with cache configuration.
  • Author policies: Write ALFA policies in the Policies editor, in code, split, or graphical view.
  • Compose domains: Bundle policies, attributes, and attribute connectors into versioned domains that you can roll back and that ADS fetches by name.
  • Review access: Answer questions such as "What can Alice do?" or "Who can access application X?" with Policy insights, without reading the policies.
  • Collaborate safely: Stage changes privately in My workspace before sharing them, follow what changed in the Activity feed, and move configurations between environments with import and export.
  • Get help from AI: Use the experimental AI assistant to explain, validate, and test policies in plain language.
  • Administer the platform: Manage users, clients, audit logs, and the license, and deploy Authorization Hub on Kubernetes.
SHARE YOUR FEEDBACK

Help us improve Authorization Hub by sharing suggestions, ideas for improvement, or usability concerns. Click the profile icon at the top right of the interface and select Share your feedback. For technical issues or urgent assistance, contact Axiomatics Support directly.

Why ABAC?​

Traditional role-based access control (RBAC) grants access based on a user's role alone. ABAC goes further as it factors in who is making the request, what they want to do, which resource they are targeting, and the context of the request (such as time of day, location, or device type).

This lets you express fine-grained policies that RBAC cannot, such as:

  • "A nurse can view a patient's records only during their assigned shift."
  • "A contractor can access project files only from a corporate device."
  • "A manager can approve expenses only for their own department."

Without ABAC, satisfying these rules requires an ever-growing number of roles, which quickly becomes unmanageable.

How authorization works​

ABAC operates across three distinct planes:

  • Control plane: Where you define, manage, and store policies, attributes, and attribute connectors. This is Authorization Hub.
  • Decision plane: Acts as the Policy Decision Point (PDP) and evaluates access requests against your policies. It fetches attribute values at runtime, checks them against the policy rules, and returns a decision such as Permit or Deny. In the Axiomatics platform, this is the Access Decision Service (ADS)Opens in a new tab. Audit and access review reports are typically generated here through SIEM services.
  • Enforcement plane: Implemented by a Policy Enforcement Point (PEP) in your applications, gateways, or proxies. It acts on the PDP's decision, either allowing or blocking the requested action.

Authorization Hub gives the PDP everything it needs to evaluate requests accurately. It is not in the runtime decision path: once ADS has loaded its domain, decisions do not depend on Authorization Hub being reachable.

To learn how Authorization Hub, ADS, and Axiomatics Policy DevOpsOpens in a new tab fit together, start with the Authorization Management Platform overview.

Authorization policy lifecycle​

Managing authorization is an ongoing cycle. Authorization Hub fits into the following workflow:

  1. Define requirements: Write authorization requirements in plain English and track them with your preferred tools.
  2. Identify attributes: Define the attributes that describe users, resources, actions, and context. Map them to their data sources, such as user directories (LDAP), databases (SQL), APIs, and so on.
  3. Author policies: Write policies in the ALFA language using the built-in editor or your IDE.
  4. Test: Use Axiomatics Policy DevOpsOpens in a new tab to verify behavior, catch errors, and confirm policies work consistently across environments.
  5. Deploy: Bundle policies, attributes, and attribute connectors into a domain that the PDP can fetch and apply to access requests.
  6. Audit and review: Use your SIEM to analyze the access audit trail and Policy insights to generate access review reports, such as "What can Alice do?" or "Who can access application X?".
info

Authorization Hub currently covers steps 2, 3, 5 and partially 6 while steps 1 and 4 use external tooling. The experimental AI assistant can also validate and test policies while you author them.

ALFA language​

ALFA (Abbreviated Language for Authorization) is a domain-specific language for writing authorization policies. Its syntax resembles Java and C#, making it familiar to most developers. The main concept for all policies written in ALFA is permit and deny which is close to a natural language thinking process. Policies nest hierarchically, which keeps large policy sets organized and makes evaluation efficient. Read the ALFA documentationOpens in a new tab to learn more.

Notices​

AXIOMATICS® is a registered trademark of Axiomatics AB, corporate identification no. 556708-1012, Sweden. Other trademarks are the property of their respective owners.

Except as otherwise expressly agreed in writing by Axiomatics AB, information in this document does not constitute in any way a representation, warranty or commitment on the part of Axiomatics.