The platform components
Before the components, one concept ties them together: the authorization domain, a self-contained package holding everything needed to evaluate access requests:
- Policies: the ALFA rules, including how their results are combined into one decision (at least one policy is required).
- Attributes: the vocabulary the policies use.
- Attribute connectors: links to external data sources that supply attribute values at decision time.
The domain is what Authorization Hub or APD produces and what ADS consumes, so it can be versioned, promoted and deployed as one unit.
Authorization Hub: the control plane
Authorization Hub is the central place to manage ABAC across an organization. It gives the PDP everything it needs to evaluate requests.
What you do in it
- Dictionary: define attributes that describe users, resources, actions, and context.
- Attribute connectors: configure standard connectors (LDAP, SQL, Table, HTTP, and JSON/XML/JWT parsers) and map their results to attributes.
- Policies: author ALFA in the built-in editor, as one policy package per project in the UI.
- Domains: create a domain in a project from its policies, attributes, connectors and cache settings. Each save stores a new version that you can roll back to. ADS fetches the domain by project and domain name.
- Policy insights: run access-review reports ("What can Alice do?", "Who can access application X?").
- Administration: user invitations and role assignment, license status, machine client and remote endpoint management, and audit logging.
How it is organized
Work happens in projects: isolated spaces per team, so teams cannot overwrite one another's work. Every member, whether a human user or a machine client, holds a project role that determines their level of access and editing privileges. Each project has an activity feed and a personal workspace for staging changes before saving.
Interfaces
A web UI plus REST APIs, for example for managing policy packages programmatically from a pipeline.
Access Decision Service (ADS): the decision plane
ADS is a cloud-native PDP: a standalone service that evaluates access requests and returns decisions. It keeps access-control logic out of application code behind a standards-based REST API.
At request time, ADS:
- receives a structured authorization query from a PEP
- uses the policies of its active domain, already loaded into the engine
- uses attribute values from the request, and calls attribute connectors for anything missing
- evaluates, applies the combining algorithm, and returns the decision to the PEP
Key characteristics
- Standards: implements XACML 3.0 and can optionally expose AuthZEN authorization endpoints.
- APIs: REST APIs for decisions, for reverse queries (see below) and for administration (health checks, metrics, system info).
- Domain loading: ADS reads a single domain from a file or a remote source. It can be configured to poll the source and activate a changed domain without a restart: in-flight requests finish on the old version and new requests use the new one. An invalid update is rejected and the last valid domain stays active.
- Deployment: runs as a standalone service, either as a JAR or deployed on Kubernetes.
- Engine modes: can run as a decision engine only (the default), as a reverse-query engine only (no decision endpoints), or both.
Contextual Authorization Query (CAQ)
A reverse query asks the opposite question to a normal request: instead of "is this request permitted?", it asks "what conditions must hold to get this decision?". It answers questions like "Which documents can employees in Sales access?".
CAQ powers Policy insights in Authorization Hub, which needs an ADS instance with reverse queries enabled.
Axiomatics Policy DevOps (APD): the toolchain
APD treats ALFA policies and attribute connectors as code. It is built on Gradle and JUnit and is used from your IDE (for example VS Code or IntelliJ) and your CI/CD pipeline.
What it provides
- Test-driven development for policies: unit tests (request attributes set directly), attribute connector tests, and system tests that fetch attributes through connectors. Tests run on an embedded engine, so they need no ADS.
- Visual tracing of policy evaluation in test reports (a preview feature).
- Local runs: start ADS with your built domain, or with a domain stored in Authorization Hub, to test against it.
- Build: compile policies and generate the authorization domain.
- Delivery integrations: Authorization Hub, a container image build context for your pipeline, or your own custom delivery.
- Version control and traceability by keeping policies in git.
Recommended workflow
Capture requirements, define the dictionary, write failing tests, write policies until tests pass, then create attribute connectors.
Summary
| Authorization Hub | ADS | APD | |
|---|---|---|---|
| Plane | Control | Decision | Development and delivery |
| Primary users | Policy admins, authors, reviewers | Platform and ops teams - applications call it | Policy developers, CI/CD pipelines |
| Works with | Domains, projects, ALFA | Authorization requests, domain | ALFA, Gradle, JUnit, git |
| Produces / serves | Domains that ADS can fetch | Decisions | Tested policies and the built domain |