Page Comparison

...

• Identity Server as an XACML engine
• Adding Fine-grained Authorization for Proxy Services in ESB
• Writing XACML policies in WSO2 Identity Server

• Writing XACML3 Policies in WSO2 Identity Server

For more general information on XACML, please see the following:

Introducing XACML

XACML (eXtensible Access Control Markup Language) is an XML-based language for access control that has been standardized by the Technical Committee of the OASIS consortium. XACML is popular as a fine grain authorization method among the community. However, there are aspects of XACML which surpass it being just a fine grain authorization mechanism.

...

Most of the organizations still use legacy systems with inbuilt authorization logicslogic. Sometimes, one organization contains a large number of information systems and applications that each system or application uses for their own process of authorization. Today, authorization has become more complex because users within organization organizations as well as outside the organization need access to shared data and have the need to collaborate efficiently. Therefore It has been very hard to manage those legacy, custom authorization systems. However, XACML offers a solution to this problem.

...

• Authorization logics are hard coded into the programing programming source code
• Authorization logics are stored in a databases that could be only readable and understandable by the underlying application

...

• is a standard which is ratified by OASIS standards organization.
• is a policy language implemented using XML.
• supports Attribute Based Access Control (ABAC) and evaluation can be done with the additional data retrieved from Policy Information Point (PIP) which is defined by the XACML reference architecture.
• contains reference architecture which is provided to externalize the authorization system. The Policy Decision Point (PDP) offers authorization as a service in your infrastructure. Authorization algorithms can be removed from the application logic and applications can query the PDP via their own Policy Enforcement Points (PEP).
• provides fine-grained authorization with higher level of abstraction by means of policies and rules.
• supports dynamic evaluation of policies by using the Policy Information Point (PIP).

Improvements in XACML 3.0

The XACML 3.0 core specification highlights the following main changes in comparison with XACML 2.0.

Custom attribute categories

Custom attribute categories can be defined with XACML 3.0. However, in XACML 2.0, attributes have been organized into subject, resource, environment or action. For example, consider that you want to create an attribute category called “foo” in your policy and request. You can do it with XACML 3.0 without any issue. According to the XACML 3.0 policy schema, the category of XACML element is identified by a XML attribute called “Category”. 

In XACML 2.0 Policy, you can define the attribute designator element as follows, However, it must be a pre-defined category such as subject, resource, environment or action.

<ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>

In a XACML 3.0 Policy, you can define it as follows. Category can be any thing as it is defined as an attribute of the AttributeDesignator element.

<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" Category="resource" DataType="http://www.w3.org/2001/XMLSchema#string"/>

Improvements in Obligation

There are several improvements with Obligation in XACML 3.0 when compared to 2.0.

One of the main improvements is the introduction of Obligation Expressions. This adds dynamic expressions into the obligation statements. For a more indepth understanding, see the following example:

Let assume that you want to do following with the Obligation: “On deny, inform the PEP to send an email to the user”.

In XACML 2.0, you need to define the obligation element with the user email statically.

<Obligation ObligationId="send-email" FulfillOn="Deny">
	<AttributeAssignment AttributeId="email" DataType="http://www.w3.org/2001/XMLSchema#string">user@foo.com</AttributeAssignment>
</Obligation>

However, the user would not be same for each XACML request that is evaluated. Therefore it is not possible to configure the email statically in the Obligation element. Obligation can only inform PEP to send an email to user (it lets the PEP figure out the value of user’s email).

<Obligation ObligationId="send-email" FulfillOn="Deny">
	<AttributeAssignment AttributeId="text" DataType="http://www.w3.org/2001/XMLSchema#string">please send email to user</AttributeAssignment>
</Obligation>

However, in XACML 3.0, the email of each user can be retrieved using PIP in a dynamic manner as we can define an expression element inside the ObligationExpression. Therefore Obligation can inform PEP to send an email to user@foo.com address.

<ObligationExpression ObligationId="send-email" FulfillOn="Deny">
	<AttributeAssignmentExpression AttributeId="email" DataType="http://www.w3.org/2001/XMLSchema#string">
		<AttributeDesignator AttributeId="email" Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"/>
	</AttributeAssignmentExpression>
</ObligationExpression>

In XACML 2.0, obligations can only be added to policies and policy sets. However, with XACML 3.0, rules can also contain obligations.

Introduce of Advice

Advice is a newly introduced feature with XACML 3.0 which is similar to obligations. PEPs do not have to comply with advice statements; PEPs can consider or discard the statement. A common scenario is to explain why something was denied: “User bob is denied because he does not have a valid email”.