Overview[1]#

XACML stands for eXtensible Access Control Markup Language. XACML is a Policy Based Management System that defines a declarative Access Control policy language implemented in XML and a processing model describing how to evaluate authorization 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 authorization implementations by multiple vendors.

XACML is primarily an Attribute Based Access Control (ABAC) system, where attributes associated with an Entity or Resource Action or resource are inputs into the decision of whether a given Entity may access a given resource and perform a particular Resource Action.

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 authorization decision from the point of use. When authorization decisions are baked into client applications (or based on local machine users 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 authorization decision, authorization policies can be updated on the fly and affect all clients immediately.

Core RBAC and XACML#

Core RBAC, includes the following five basic data elements:

• Users - Users are implemented using XACML Subjects. Any of the XACML Subject Category values may be used, as appropriate.
• Roles - Roles are expressed using one or more XACML Subject Attributes. The set of roles is very application and policy domain-specific, and it is very important that different uses of roles not be confused. For these reasons, XACML is not attempting to define any standard set of roles. It is recommended that each application or policy domain agree on and publish a unique set of AttributeId values, DataType values, and <AttributeValue> values that will be used for the various roles relevant to that domain.
• Objects - Objects are expressed using XACML Resources.
• Operations - Operations are expressed using XACML Actions.
• Permissions - Permissions are expressed using XACML Role <PolicySet> (RPS) and Permission <PolicySet> (PPS) instances as described in previous sections.

Core RBAC requires support for multiple users per role, multiple roles per user, multiple permissions per role, and multiple roles per permission. Each of these requirements can be satisfied by XACML policies based on this Profile as follows. Note, however, that the actual assignment of roles to users is outside the scope of the XACML PDP.

XACML Versions#

• version 2.0 was ratified by OASIS standards organization on 1 February 2005. As of 2007,
• version 3.0 adds generic attribute categories for the evaluation context and policy delegation profile (administrative policy profile) was standardized in January 2013
  • Contains REST Profile of XACML
  • Multiple Decision Profile: Multiple resource request (XACML 2.0) was renamed Multiple Decision Profile (XACML 3.0) and enhanced with new variants. This profile lets a requestor –typically the Policy Enforcement Point (PEP) ask several questions in one go to which the Policy Decision Point (PDP) returns one answer with multiple decisions. This profile is particularly useful in web-portal-based scenarios where decisions have to be reached for different parts of a portal within a given page for a given user. It enhances performance as it reduces communication overhead between PEP and PDP.
  • Delegation: the ability to delegate administrative rights in XACML is new as of XACML 3.0. Delegation enables global administrators to delegate constrained administrative rights to local administrators. For instance, a global administrator can define access control (AC) policies for an entire set of resources within an organization. The administrator can also delegate the right to Administrator A to manage a set of resources SA. Administrator A’s rights to define access control rules are constrained by the delegation policy that the global administrator has defined. Delegation is most useful in federation scenarios, cloud-based scenarios, and in environments where the domains to secure are so vast that they require local knowledge to define relevant policies.
  • Obligation expressions: this new feature lets administrators define statements that are returned from the PDP to the PEP along with a PERMIT or DENY decision. The receiving PEP has to comply with that statement before it can act on the decision. An example of an obligation is as follows:
    Request: Can Doctor X access Patient Y’s data?
    Response: Permit, he can, provided you, the PEP, write in the hospital access log, the fact that Doctor X has had access to Patient Y’s data.
  • Advice expressions: this new feature is similar to obligations with the exception that PEPs do not have to comply with the statement. PEPs can consider or discard the statement.
  • Policy combination algorithms: in XACML, policies are combined together to produce a single decision. Each policy can reach different decisions. These decisions must be combined to return a single result. XACML 3.0 enhances XACML 2.0’s existing combination algorithms.
  • New attribute functions and datatypes: XACML 3.0 brings in new datatypes and new functions that can be used for the attributes and attribute matching. In particular XACML 3.0 utilizes XPath to manipulate attributes.
  • New profiles: XACML 3.0 brings additional profiles. In particular a new profile for export compliance has been produced to help author policies that can cater for export compliance scenarios. Similarly, a new profile for Intellectual Property Control (IPC) has been introduced.
  • Enhanced profiles: the Hierarchical Resource Profile present in XACML 2.0 has been reviewed and enhanced in XACML 3.0.

For the latest information visit the OASIS eXtensible Access Control Markup Language (XACML) TC site and their Wiki.

XACML is dead [2]#

Here are the reasons why we predict XACML is dead:

• Lack of broad adoption. The standard is still not widely adopted with large enterprises who have written their authorization engines.
• Inability to serve the federated, extended enterprise. XACML was designed to meet the authorization needs of the monolithic enterprise where all users are managed centrally in Microsoft Active Directory. This is clearly not the case today: companies increasingly have to deal with users whose identities they do not manage.
• PDP does a lot of complex things that it does not inform the PEP about. If you get a 'no, you can't do that' decision in the application from the PEP, you'd want to know why. Our customers tell us that this can prove to be very difficult. The PEP may not be able to find out from the complex PDP evaluation process why an authorization was denied.
• Not suitable for Cloud computing and Distributed system deployment. While some PEPs can bundle the PDP for faster performance, using a PEPs in a cloud environment where you only have a WAN link between a PDP and a PEP is not an option.
• Commercial support is non-existent. There is no software library with PEP support. Major ISVs have not implemented externalized authorization or plugin frameworks for externalized authorization. Replacing native SharePoint authorization with an Entitlement Management PEP is a nightmare requiring a one-off, non-standard, non-repeatable development and operations process.
• Refactoring and rebuilding existing in-house applications is not an option. Entitlement Management deployment requires a refactoring of the application to use the PEP hooks for centralized, externalized authorization. This is not a reality at most companies. They cannot just refactor applications because of a different authorization model (sometimes, especially with mainframe applications the authorization model is not even understood well enough to do this…)
• OAuth 2.0 supports the Mobile Device application endpoint in a lightweight manner. XACML today largely supports web based applications. While OAuth's current profiles are not a full-blown replacement for XACML functionality, we see that OAuth's simplicity made it the de-facto choice for mobile and also non-mobile applications. !! More Information

There might be more information for this subject on one of the following:

• API-Gateway
• Abbreviated Language For Authorization
• Adaptive Policy-based Access Management
• Attribute Based Access Control
• DirX Access
• Dynamic Authorization Management
• EXtensible Access Control Markup Language
• Entitlement Management System
• Glossary Of LDAP And Directory Terminology
• Ian Glazer
• NIST RBAC
• Neo-Security Stack
• OpenAM
• Policy Based Management System
• Policy Decision Point
• REST Profile of XACML
• SAML V2.0
• Web Service Security Specifications
• XACML

---

• [#1] - XACML - based on information retrieved 2013-09-06