XACML stands for "eXtensible Access Control Markup Language". The standard defines a declarative access control policy language implemented in XML and a processing model describing how to evaluate access requests according to the rules defined in policies.
As a published standard specification, one of the goals of XACML is to promote common terminology and interoperability between access control implementations by multiple vendors. XACML is primarily an Attribute Based Access Control system (ABAC), where attributes (bits of data) associated with a user or action or resource are inputs into the decision of whether a given user may access a given resource in a particular way. Role-based access control (RBAC) can also be implemented in XACML as a specialization of ABAC.
The XACML model supports and encourages the separation of the access decision from the point of use. When access decisions are baked into client applications (or based on local machine userids and Access Control Lists (ACLs)), it is very difficult to update the decision criteria when the governing policy changes. When the client is decoupled from the access decision, authorization policies can be updated on the fly and affect all clients immediately.
- 1 History
- 2 Terminology
- 3 Policy Elements
- 4 Combining Algorithms
- 5 XACML 3.0
- 6 Developer Orientation
- 7 See also
- 8 Notes
- 9 External links
The first committee specification of XACML 3.0 was released August 10, 2010.
The latest version, XACML 3.0, was standardized in January 2013.
The first version of administrative policy profile working draft was publicly released on April 1, 2009.
Non normative terminology (following RFC 2904, except for PAP)
|PAP||Policy Administration Point - Point which manages access authorization policies|
|PDP||Policy Decision Point - Point which evaluates access requests against authorization policies before issuing access decisions|
|PEP||Policy Enforcement Point - Point which intercepts user's access request to a resource, makes a decision request to the PDP to obtain the access decision (i.e. access to the resource is approved or rejected), and acts on the received decision|
|PIP||Policy Information Point - The system entity that acts as a source of attribute values (i.e. a resource, subject, environment)|
|PRP||Policy Retrieval Point - Point where the XACML access authorization policies are stored, typically a database or the filesystem.|
XACML is structured into 3 levels of elements:
- Policy, and
A PolicySet can contain any number of Policy elements and PolicySet elements. A Policy can contain any number of Rule elements.
Attributes & Categories
Policies, Policy Sets, Rules and Requests all use Subjects, Resources, Environments, and Actions.
- A Subject element is the entity requesting access. A Subject has one or more Attributes.
- The Resource element is a data, service or system component. A Resource has one or more Attributes.
- An Action element defines the type of access requested on the Resource. Actions have one or more Attributes.
- An Environment element can optionally provide additional information.
XACML provides a target, which is basically a set of simpliﬁed conditions for the subject, resource, and action that must be met for a policy set, policy, or rule to apply to a given request. Once a policy or policy set is found to apply to a given request, its rules are evaluated to determine the access decision and response.
PolicySet, Policy and Rule can all contain Target elements.
Conditions only exist in rules. Conditions are essentially an advanced form of a target which can use a broader range of functions and more importantly can be used to compare 2 or more attributes together e.g. subject-id==doctor-id. With conditions, it is possible to implement segregation of duty checks or relationship-based access control.
Within XACML, a concept called obligations can be used. An obligation is a directive from the Policy Decision Point (PDP) to the Policy Enforcement Point (PEP) on what must be carried out before or after an access is approved. If the PEP is unable to comply with the directive, the approved access may or must not be realized. The augmentation of obligations eliminates a gap between formal requirements and policy enforcement. An example of an obligation could look like this:
Access control rule:
Allow access to resource MedicalJournal with attribute patientID=x if Subject match DesignatedDoctorOfPatient and action is read with obligation on Permit: doLog_Inform(patientID, Subject, time) on Deny : doLog_UnauthorizedLogin(patientID, Subject, time)
The XACML's obligation can be an effective way to meet formal requirements (non-repudiation for example) that can be hard to implement as access control rules. Furthermore, any formal requirements will be part of the access control policy as obligations and not as separate functions, which makes policies consistent and centralization of the IT environment easier to achieve.
What happens in XACML if there are 2 rules (or policies) that contradict each other? Imagine for instance a first rule that would say managers can view documents and a second rule that would say no one can work before 9am. What if the request is about Alice trying to view a document at 8am? Which rule wins? This is what combining algorithms tell us. They help resolve conflicts.
XACML defines a number of combining algorithms that can be identified by a RuleCombiningAlgId or PolicyCombiningAlgId attribute of the <Policy> or <PolicySet> elements, respectively. The rule-combining algorithm defines a procedure for arriving at an access decision given the individual results of evaluation of a set of rules. Similarly, the policy-combining algorithm defines a procedure for arriving at an access decision given the individual results of evaluation of a set of policies.
Additional details on the different combining algorithms and their truth tables can be found on the Axiomatics Developer Blog.
New in XACML 3.0
The implementation of delegation is new in XACML 3.0. The delegation mechanism is used to support decentralized administration of access policies. It allows an authority (delegator) to delegate all or parts of its own authority or someone else's authority to another user (delegate) without any need to involve modification of the root policy.
This is because, in this delegation model, the delegation rights are separated from the access rights. These are instead referred to as administrative control policies. Access control and administrative policies work together as in the following scenario:
A partnership of companies' many services are protected by an access control system. The system implements the following central rules to protect its resources and to allow delegation:
Access control rules:
Allow access to resource with attribute WebService if subject is Employee and action is read or write.
Administration control rules:
Allow delegation of access control rule #1 to subjects with attribute Consultant. Conditions: delegation must expire within 6 months, resource must not have attribute StrictlyInternal.
(Attributes can be fetched from an external source, e.g. a LDAP catalog.)
When a consultant enters the corporation, a delegation can be issued locally by the consultant's supervisor, authorizing the consultant access to systems directly.
The delegator (the supervisor in this scenario) may only have the right to delegate a limited set of access rights to consultants.
Other new features of XACML 3.0 are listed at http://www.webfarmr.eu/2010/07/enhancements-and-new-features-in-xacml-3-axiomatics/
The XACML TC is also publishing a list of changes here: http://wiki.oasis-open.org/xacml/DifferencesBetweenXACML2.0AndXACML3.0
In 2013 and 2014, the XACML Technical Committee focused on designing new profiles to facilitate developer integration. These include:
- The REST profile of XACML written by Remon Sinnema of EMC
- the JSON profile of XACML written by David Brossard of Axiomatics
- The ALFA profile of XACML written by Pablo Giambiagi, Srijith Nair, and David Brossard of Axiomatics
All three profiles were showcased at the Cloud Identity Summit 2014 in Monterey, California. Using these profiles, integrating fine-grained authorization into applications becomes much easier.
- Role-based access control
- Attribute Based Access Control
- Mandatory access control
- Discretionary access control
- TAS3 - Specifies 4-point access control using XACML
- Model-driven security
- "XACML 3.0 - committee specification 01.". OASIS (oasis-open.org). Retrieved 10 August 2010.
- eXtensible Access Control Markup Language (XACML) V3.0 approved as an OASIS Standard, eXtensible Access Control Markup Language (XACML) V3.0 approved as an OASIS Standard.
- "XACML v3.0 Hierarchical Resource Profile Version 1.0.". OASIS (oasis-open.org). Retrieved 1 April 2009.
- XACML v3.0 Administrative Policy Version 1.0
- Axiomatics Language for Authorization (ALFA), a free eclipse plugin for XACML 3.0 authoring
- eXtensible Access Control Markup Language
- XACML for Authorization
- HERAS-AF: An Open Source Project providing an XACML-based Security Framework
- JBoss XACML - Open Source LGPL licensed library
- OASIS XACML committee website
- OASIS declaration of issues with two software patents of IBM
- XACML 2.0 PDP and PAP implemented as Axis2 web services
- XACML authorization for many PAM enabled applications
- SICSACML XACML
- ZXID http://zxid.org
- OpenAz - Java and C++ Language bindings for XACML with prototypes based on SUN XACML lib
- Xacml4j XACML 2.0 & 3.0 implementation in Java programming language