This documentation is for WSO2 Identity Server 5.3.0 . View documentation for the latest release.

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • Can business managers (who should determine how access controls would be implemented) define and modify authorization logics?
  • Can we find new IT technicians to manage these legacy systems? Especially when people who developed the system, left the organization
  • Can authorization logics be modified without any source code changes in an dynamic way?
  • Is authorization system capable for evaluating following rule? “X resource can be accessed by the Users who are from domain and whose age is greater than 21 years old”
  • If we are going to implement a new information system with the organization, can we re-use the authorization logics of a legacy system?
  • Can achieve find-grant authorization without defining large number of static combinations?
  • Is authorization systems capable of answering following questions: “Can a user, BobAlex, transfer X amount from Y current account at 1.00pm?“


  • 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
Attribute Based Access Control(ABAC)

ABAC is an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes etc.). This model supports Boolean logic, in which rules contain "IF, THEN" statements about who is making the request, the resource, and the action. For example: IF the requestor is a manager, THEN allow read/write access to sensitive data.

  • 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).
  • can publish multiple policies into external PDPs.


Policy Decision Point (PDP) evaluates policies against access requests provided by Policy Enforcement Points (PEP). To provide the decisions, PDP may also need to query a Policy Information Point (PIP) to gather descriptive attributes about the user or any other missing attribute in the request. Policy Administration Point (PAP) is used to manage the PDP and PIP functionality.

Image RemovedImage Added

XACML terminology


  • Policy Enforcement Point (PEP): The system entity that performs access control by making decision requests and enforcing authorization decisions. Basically this is the entity that sends the XACML request to the Policy Decision Point (PDP) and receives an authorization decision.
  • Policy Decision Point (PDP): The system entity that evaluates an applicable policy and returns an authorization decision.
  • Policy Information Point (PIP): The system entity that acts as a source of attribute values. Basically if there are missing attributes in the XACML request that is sent by PEP, PIP would find them for the PDP to evaluate the policy.
  • Policy Administration Point (PAP): The system entity that creates a policy or policy set and manages them.

XACML engine architecture


The WSO2 Identity Server is a major player in the XACML and open source world. The Identity Server supports XACML 3.0, which is based on Balana XACML implementation. As the source code, distribution and documentation are available for free, it is possible to analyze and understand the architecture behind it. This You can find source code from here. This section provides some information regarding the architecture of the XACML engine (or the entitlement engine) of the WSO2 Identity Server.


When you are writing a new module, you need to consider the following in addition to policy retrieving and re-initializing.

  • Policy ordering - The order which policies are evaluated.
  • Policy combining algorithm
    Excerpt Include
    Creating a XACML Policy
    Creating a XACML Policy
  • How to retrieve referenced policies


This is used to retrieve children or descendant resources of a given root level resource value. Basically it is used to fulfill the requirement of a multiple decision profile. The implementation is same as the PIP attribute finder module. By default, WSO2 Identity Server is shipped with DefaultResourceFinder (which is the implementation of PIPResourceFinder) that communicates with Carbon registry resources.with Carbon registry resources.

XACML policy language structure and syntax

In order to render an authorization decision, it must be possible to combine the two separate policies to form the single policy applicable to the request.

XACML defines three top-level policy elements:

  •  <Rule> -  Element that contains a Boolean expression that can be evaluated in isolation, but that is not intended to be accessed in isolation by a PDP.  So, it is not intended to form the basis of an authorization decision by itself.  It is intended to exist in isolation only within an XACML PAP, where it may form the basic unit of management.
  • <Policy> - Element that contains a set of <Rule> elements and a specified procedure for combining the results of their evaluation.  It is the basic unit of policy used by the PDP, and so it is intended to form the basis of an authorization decision
  • <PolicySet> - Element that contains a set of <Policy> or other <PolicySet> elements and a specified procedure for combining the results of their evaluation.  It is the standard means for combining separate policies into a single combined policy.

As XACML is used in Attribute Based Access Controling, in XACML all the attributes are categorized into four main categories: But from XACML 3.0, custom categories are also supported.

  • Subject
  • Resource
  • Action 
  • Environment

A Rule is the most elementary unit of policy.  It may exist in isolation only within one of the major actors of the XACML domain. The main components of a Rule are as follows:

  • <Target> - This defines the set of requests to which the rule is intended to apply in the form of a logical expression on attributes in the request.
  • <Effect> - The effect of the rule indicates the rule-writer's intended consequence of a "True" evaluation for the rule.  Two values are allowed: "Permit" and "Deny".
  • <Condition> - A Boolean expression that refines the applicability of the rule beyond the predicates implied by its target.  Therefore, it may be absent.
  • <ObligationExpressions> - Obligation expressions may be added by the writer of the policy.When a PDP evaluates a policy containing obligation expressions, it evaluates the obligation expressions into obligations and returns certain of those obligations to the PEP in the response context.
  • <AttributeSelector> - This allows the policy to specify an attribute with given identifier, category and data type. AttributeSelector on the other hand provides a mean to lookup the value of attributes using a XPath query by specifying the data type and XPath expression. Attribute selectors are then executed against the XML content that may have been sent along in the initial XACML request.

A sample XACML 3.0 policy is as follows:

Code Block
<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" PolicyId="samplePolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides" Version="1.0">
				<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
					<AttributeValue DataType="">read</AttributeValue>
					<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action" DataType="" MustBePresent="true"/>
	<Rule Effect="Permit" RuleId="permit"/>

Improvements in XACML 3.0


Code Block
<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" Category="resource" DataType=""/>

Improvements in Obligation

 Category="resource" DataType=""/>

Improvements in Obligation

In general obligation can have following,

  • Obligations have an identifier, which is used to distinguish different types of obligations
  • Obligations can have arguments
  • Obligations apply to Permit (or Deny) decisions only

A PDP will return, as part of a Permit or Deny response, a (possibly empty) subset of the obligations that appear in the policy.

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:


Code Block
<ObligationExpression ObligationId="send-email" FulfillOn="Deny">
	<AttributeAssignmentExpression AttributeId="email" DataType="">
		<AttributeDesignator AttributeId="email" Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" DataType="" MustBePresent="false"/>

       In XACML 2.0, obligations can only be added to policies and policy sets. However, with XACML 3.0, rules can also contain obligations. At the root of all XACML policies is a policy or a policy set. A policy represents a single access control policy, expressed through a set of rules. A policy set is a container that can hold other policies or policy sets, as well as references to policies found in remote locations.


Advice is a newly introduced feature with XACML 3.0 which . Advice is similar to obligations and it shares much of its syntax. The difference is contractual: the PEP can disregard any advice it receives. 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 Alex is denied because he does because Alex does not have a valid email”.

The XACML specification says that any advice returned with a decision can be safely ignored by compliant PEPs. This means that PEPs should work as described in the previous section, regardless of what the PEP does with the advice it may receive. For example, a PEP must allow access if it receives a Permit decision with no obligations, regardless of any advice in the decision.

Improvements in Target

Since it is possible to define custom attribute categories, there are improvements in some related elements in the XACML 3.0 policy, when compared to 2.0. With XACML 3.0, the Target element can be used to define more complex authorization logic within itself when compared with 2.0.


As an example, let look at a Target element. In XACML 2.0, we have an AND relationship between foo1 and foo2 resources and an OR relationship between bar1 and bar2 actions. However, we cannot create an OR relationship between a foo1 resource and bar1 action. so we cannot define something such as “Target would be matched when Bob Alex can access the foo resource or do a bar action” by using the Target element.


XACML 3.0 has an AND relationship between “foo” resource and “bar1″ role and an OR relationship between “bar2″ action. So we cannot define something as “Target would be matched, when Bob Alex can access foo resource and do bar1 action or do bar2 action”.


This is also a new profile which comes with XACML 3.0. This allows you to define policies about who can write policies about what. For example, “Bob  “Alex may issue a policy but only about resources in department X”.