ABAC in five minutes
From roles to attributes
Role-Based Access Control (RBAC) binds permissions directly to predefined roles, and assigns users to those roles. It works until rules depend on anything else: which record, what time, from which device. Then you need ever more roles, and the model becomes unmanageable. Attribute-based access control (ABAC) resolves this issue by replacing role-to-permission mapping with dynamic boolean policy evaluation. Instead of hardcoding access decisions into static identity buckets, ABAC evaluates claims across four independent vectors at runtime:
| Category | Question it answers | Examples |
|---|---|---|
| Subject | Who is asking? | department, clearance, employment type |
| Resource | What are they acting on? | classification, owner, status |
| Action | What do they want to do? | read, approve, delete |
| Environment | In what context? | time of day, location, device |
Instead of asking "What role does this user have?", ABAC asks: "Given who this user is, what they are trying to access, what they want to do, and current real-world conditions, does policy permit it?".
Policy-based access control (PBAC) is a closely related term. Axiomatics uses both to describe the same externalized, dynamic model: policies, not hardcoded permissions, drive every decision.
The XACML architecture: PEP, PDP, PIP
Axiomatics follows the XACML reference architecture, which separates enforcing a decision from making it.
- PEP (Policy Enforcement Point): lives in your application, API gateway, or proxy. It intercepts the request, asks the PDP, and allows or blocks accordingly.
- PDP (Policy Decision Point): evaluates policies and returns a decision: Permit, Deny, Not Applicable or Indeterminate.
- PIP (Policy Information Point): any external source of attribute values, such as a directory or database.
Because authorization logic lives in the PDP and not in application code, one set of policies applies consistently across every application that calls it.
Policies: ALFA and XACML
XACML is the OASIS standard for the policy language, the request/response protocol and the reference architecture. ALFA (Abbreviated Language for Authorization) is a developer-friendly syntax, similar to Java or C#, that compiles to XACML 3.0. You write ALFA, the engine runs XACML.
When several rules match a request, a combining algorithm (for example deny-overrides, permit-overrides or first-applicable) decides how their results merge into one decision.
Three planes
It helps to think of an ABAC deployment as three planes:
| Plane | What happens there | Platform component |
|---|---|---|
| Control | Define, manage and store policies, attributes and attribute connectors | Authorization Hub |
| Decision | Evaluate requests against policies, fetch attributes, return decisions | Access Decision Service |
| Enforcement | Act on the decision | Your PEPs (applications, gateways) |
Axiomatics Policy DevOps sits alongside the control plane: it is how policies get built and verified before they are deployed. The next page looks at each component in turn.