XACML stands for eXtensible Access Control Markup Language. It is a declarative access control policy language implemented in XML and a processing model, describing how to interpret the policies.
Latest version 2.0 was ratified by OASIS standards organization on 1 February 2005. The planned version 3.0 will add generic attribute categories for the evaluation context and policy delegation profile (administrative policy profile).
The first committee draft of XACML 3.0 was released 16 April 2009. [1]
The first version of administrative policy profile working draft was publicly released on 1 April 2009.[2]
Terminology
Non normative terminology
| Term |
Description |
| PAP |
Policy Administration Point - Point which manages policies |
| PDP |
Policy Decision Point - Point which evaluates and issues authorization decisions |
| PEP |
Policy Enforcement Point - Point which intercepts user's access request to a resource and enforces PDP's decision. |
| PIP |
Policy Information Point - Point which can provide external information to a PDP, such as LDAP attribute information. |
Policy Elements
Policies are defined with a collection of Rules. Both Rules and Requests use Subjects, Resources 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 a single Attribute.
- 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.
New in XACML 3.0
Delegation
The concept of delegation is a novel approach 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 elses authority to another user (delegate) without any need to involve modification of the root policy.
This because, in this delegation model, the delegation rights are separated from the access rights. These are instead referred to as administrative control policies[3]. 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, granting the consultant access to systems directly.
The delegator (supervisor in this scenario) may only have the right to delegate a limited set of access rights to consultants.
Obligations
Within XACML model 3.0, 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 granted. If the PEP is unable to comply with the directive, the granted access may or must not be realized. The augmentation of obligations eliminates a gap between formal requirements and policy enforcement. An use of obligations can look like the following:
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(patiendID, 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.
Implementations
See also
Notes
External links
