XACML is a language and processing model for attribute-based authorization. It describes policies and requests so a decision service can evaluate who wants to do what to which resource. The application must obtain trustworthy attributes and enforce the returned result.
Follow a request through the system
A policy administration point manages policies; a policy decision point (PDP) evaluates requests; a policy enforcement point (PEP) guards the operation. Attribute providers supply context. In a document service, the PEP might request a decision before returning a file.
Use authenticated identity and server-established resource attributes. Allowing a caller to assert an unverified “editor” role defeats the purpose of the policy. Define attribute categories, identifiers, data types, allowed issuers, and freshness requirements before writing rules.
The OASIS XACML 3.0 core specification defines the evaluation model, request/response vocabulary, and combining algorithms. The example here deliberately has a narrow fictional scope: an editor may read the demo guide.
Interpret more than yes or no
| Decision | Interpretation | Application handling to define |
|---|---|---|
| Permit | Policy evaluation permits the action | Enforce required obligations before completing it. |
| Deny | Policy evaluation denies the action | Refuse the operation and record appropriate diagnostics. |
| NotApplicable | The evaluated policy does not apply | Resolve through the enclosing policy or deny-by-default enforcement. |
| Indeterminate | Evaluation encountered an error or missing required context | Record the cause and use the defined failure policy. |
An obligation is an action the enforcement point must fulfill with a decision; advice is optional information. Define what happens when an obligation cannot be performed. A PDP response is not itself a completed access control check if the application ignores those requirements.
Combining algorithms matter when rules disagree or fail. “First applicable,” “deny overrides,” and “deny unless permit” express different behavior. Review the selected algorithm with explicit conflicting-rule and missing-attribute cases.
Inspect a small complete policy
Download the XACML policy practice pack. It includes a complete policy, four XML requests, expected results, and instructions for loading them into your chosen XACML 3.0 PDP. The namespace and identifiers follow the core specification; the role and resource names are fictional.
The policy has an empty top-level target and one Permit rule requiring role editor, action read, and resource guide. Its rule-combining algorithm is deny-unless-permit. With this policy, an applicable Permit wins; other rule outcomes produce Deny.
| Request | Inputs | Expected final decision |
|---|---|---|
| permit.xml | editor / read / guide | Permit |
| wrong-role.xml | viewer / read / guide | Deny |
| wrong-action.xml | editor / delete / guide | Deny |
| missing-role.xml | role absent / read / guide | Deny |
The missing-role case has a required attribute. Its evaluation error is collapsed to Deny by this combining algorithm; changing the algorithm can change the exposed result. The pack was checked for XML schema validity. Expected decisions are derived from the specification; run them through your selected PDP to verify that deployment.
Make enforcement testable
Load the policy into an isolated PDP and select it as the root policy using that implementation’s configuration. Submit the requests and compare actual decisions with expected-results.json. Record engine version, policy identifier/version, configuration, and diagnostics. A schema-valid policy can still be selected incorrectly or evaluated with unexpected attribute providers.
At the application boundary, test denied reads and writes for side effects and data leakage. Include an unavailable PDP, expired attributes, unknown resource, and obligations that cannot be fulfilled. Configure a clear deny-by-default path for decisions the application cannot safely satisfy.
Treat policy changes as code changes: review the reason, run previous cases and new boundary cases, stage the revision, and preserve rollback information. Log enough request context to investigate decisions while applying the same data minimization and retention rules as the protected service.