Concepts

This section explains the core ideas behind Access Decision Service (ADS) and attribute-based access control. Read these pages before moving on to configuration or deployment guides.

What is attribute-based access control (ABAC)?

Attribute-based access control (ABAC) is an approach to authorization in which the system grants or denies access based on the attributes of the user making the request, the resource being accessed, the action being performed, and the environment in which the request occurs.

In ABAC, a policy expresses rules such as "a user whose department is Finance may read documents classified as Confidential during business hours." The system evaluates each incoming access request against these rules at runtime, consulting live attribute values rather than relying on a static list of permissions.

Policy-based access control (PBAC) is a closely related term. It emphasizes that policies (not hardcoded role assignments) drive every access decision. Axiomatics uses both terms to describe the same externalized, dynamic authorization model.

ABAC and PBAC contrast with role-based access control (RBAC), where a user is assigned a fixed role and the role determines access. ABAC is more expressive: it can enforce fine-grained rules that RBAC cannot represent without an explosion of roles.

What is XACML, and why does ADS use it?

The eXtensible Access Control Markup Language (XACML) is an OASIS standard that defines:

• A policy language for writing access control rules.
• A request/response protocol that applications use to ask a policy engine whether a particular action is permitted.
• A reference architecture describing how the components of an authorization system interact.

ADS implements XACML 3.0. Using an open standard means your policies and authorization logic are not locked to a proprietary format, and you can use XACML-compatible tooling from across the ecosystem.

XACML policies are also supported through the Abbreviated Language for Authorization (ALFA), a developer-friendly syntax that compiles to XACML 3.0. ALFA makes policies easier to read and write while remaining fully compatible with the XACML standard.

The authorization architecture: PEP, PDP, and PIP

An XACML deployment separates the components that enforce access decisions from the component that makes them.

Application or API
      |
      |  (access request: subject, action, resource, environment)
      v
+---------------------+
| Policy Enforcement  |
| Point (PEP)         |  <-- your application code or a gateway/proxy
+---------------------+
      |
      |  (XACML authorization request over REST)
      v
+---------------------+       +---------------------+
| Policy Decision     | ----> | Policy Information  |
| Point (PDP) = ADS   |       | Point (PIP)         |
|                     | <---- | = Attribute         |
|  evaluates policies |       |   connectors        |
+---------------------+       +---------------------+
      |
      |  (Permit / Deny / Not Applicable / Indeterminate)
      v
+---------------------+
| Policy Enforcement  |
| Point (PEP)         |  <-- enforces the decision
+---------------------+

Policy Enforcement Point (PEP): The component in your application, API gateway, or proxy that intercepts an access request and asks ADS whether to allow it. The PEP sends a structured request and then acts on the response, allowing or blocking the operation.

Policy Decision Point (PDP): The component that evaluates policies and returns an authorization decision. ADS is the PDP. It receives the request from the PEP, loads the applicable policies from the authorization domain, fetches any missing attribute values through connectors, and returns a decision.

Policy Information Point (PIP): Any external system that holds attribute values ADS needs to evaluate a policy. Examples include an LDAP directory, a relational database, or an HTTP service. In ADS, attribute connectors act as PIPs. ADS calls them automatically during evaluation when the incoming request does not supply all required attributes.

How these concepts map to ADS components

Concept	ADS component
PDP	ADS itself
Policies	Stored in an authorization domain
Combining algorithm	Configured per domain, controls how policy results are merged
PIP	Attribute connectors (LDAP, SQL, HTTP, Table, Parser)
Attribute vocabulary	Defined in the authorization domain
XACML request/response	REST API exposed by ADS

Pages in this section

• Authorization domains: what a domain is, how it groups policies and connectors, and how to define one in YAML.
• Attribute connectors: how ADS fetches attribute values from external systems at decision time.