IntroductionThis document discusses the eXtensible Access Control Markup Language (XACML), an XML language for specifying security policies. Security policies are ways to describe who has access to what resources under what conditions. For a large enterprise, there are multiple places at which such security policies must be enforced. It would therefore seem logical to define security policies in a technology neutral way, so that they can be reused. That is exactly the purpose that XACML serves.
Intended AudienceAnyone with an interest in security: developers, administrators, HR people, etc. Basic knowledge of XML is assumed.
XACML OverviewThe following figure shows the components (orange rectangles) that make up an XACML-based security system and the data (blue ovals) that those components need as input:
- A Request comes in at a Policy Enforcement Point (PEP).
- The PEP forwards the Request to the Context Handler.
- The Context Handler asks the Policy Information Point (PIP) for Context Attributes.
- The PIP collects Context Attributes from the Subject (e.g. the role), the Resource (e.g. it's location), and the Environment (e.g. the location from where the Request is made) and returns them to the Context Handler.
- The Context Handler gets the Resource's content.
- The Context Handler presents the Request to the Policy Decision Point (PDP), along with the Context Attributes and (optionally) the Resource's content.
- The PDP makes a decision based on the security policies that the Policy Administration Point (PAP) has previously made available.
- The PDP returns its decision to the Context Handler, which returns it to the PEP.
- The PEP either grants or denies access to the Request, based on the PDP's decision
Specifying Access Control: Rules, Policies, and Policy Sets
RulesA Rule combines a Target, an Effect and a Condition. The Target specifies what the Rule is applicable for: any or all of the requested Action, the Subject requesting the Action, the Resource that the requested Action pertains to, and the Environment within which the Action is to be performed. The Effect of the Rule is to deny or permit the Action. The optional Condition further refines the applicability of the Target.
Some optional text that explains the purpose of the rule
PoliciesA Policy has a Target, a Rule-Combining Algorithm, some Rules, and some Obligations. We've seen the Target already as part of a Rule. Since a Policy also specifies a Target, a Rule need not specify one. If it doesn't, then it inherits the Target from the Policy. The Rule-Combining Algorithm specifies the procedure by which the results of evaluating the Rules are combined when evaluating the Policy. An Obligation is an operation specified in a Policy that should be performed by the PEP in conjunction with the enforcement of an authorization decision.
Some optional text that explains the purpose of the policy
Policy SetsJust as Rules can be reused in Policies, entire Policies can be reused in Policy Sets. A Policy Set contains a Target, a Policy-Combining Algorithm, a set of Policies, and some Obligations. The Policy-Combining Algorithm specifies the procedure by which the results of evaluating the component Policies are combined. Note that a Policy Set can reuse not just Policies, but also entire Policy Sets. This Lego-like structure makes it possible to build complex security policies without duplication.