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

Versions Compared


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

Today, enterprise applications seek ways of enforcing security that allows the right people to access the right resources with restrictions enforced by enterprise policies. Identity and entitlement management systems, as a whole, attempt to address these security considerations. These systems help enterprise architects and developers in their application requirement implementations and try to significantly ease the burden of security-related implementations. These identity and entitlement management systems are governed by industry standard specifications, hence supporting security requirements for heterogeneous applications becomes easy. 


Click here for more information on Access control.

This topic consists of the following sections.:


Table of Contents


Types of access control

Image Modified

The following table lists out and describes the various types of access control.

Access Control TypeDescription

Access Control Lists

Access control lists are the oldest and most basic form of access control. This access control type was primarily adopted for use in operating systems. This maintains a set of users and operations that can be performed on a resource as a mapping. This is easy to implement due to the use of maps. However, this is not scalable for larger user bases and can become difficult to manage.

Role-based Access Control

Role-based Access Control (RBAC) is an approach used to restrict access to authorized users based on their role. This is a static permission model which provides access control. It is used by the majority of enterprises with more than 500 users.

This access control type is used when all users are categorized into different roles. The roles define the resources that can be accessed by users assigned to that role. This type of access control reduces management overhead. These users and roles can also be externalized using user stores. These roles need to be managed carefully. There can be instances where a user is assigned to multiple roles. This is a subset of ABAC.

Static Permissions permissions for roles can be given by updating permission tree in WSO2 Identity Server.  Read more Click here for information on Configuring roles and permissions.

Attribute-based Access Control

Attribute-based access control (ABAC) defines a new access control paradigm whereby access rights are granted to users through the use of policies that combine attributes together.

Here, authorization happens based on attributes. This access control type addresses the limitations of role-based access control to provide a more fine-grained approach. This can be based on the attributes of the user, the environment, or even the resource itself. This is more flexible when compared with the role-based approach. There is no need to know the user prior to granting access.

Policy-based Access Control

This type of access control addresses the requirement to have a more uniform access control mechanism. This helps larger enterprises to have uniform access control for the large amount of organizational units. This is helpful when carrying out security audits.

This is the most complex form of access control system. This involves specifying policies unambiguously using XACML and using authorized attribute sources in the enterprise. Here Policy Based Access Control(PBAC) (also called Rule-based access control) is an extenstion extension of ABAC where attributes are used in writing policies.


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 that surpasses it other policy standards by being just a fine grain -grained authorization mechanism.

Although XACML was introduced as a standard by OASIS in 2003, not many organisations organizations that have been adapted it yet. This is because of most of the organizations have not shown organization's lack of interest in moving towards a XACML XACML based solution for authorization. The following may be some reasons for this:

  • Many software designer and developers do not have lack a clear understanding on the of features, importance, and advantages of XACML.
  • It is comparatively difficult to implement a XACML solution when compared with a typical JDBC or hard-coded authorization system.
  • Performances Performance of XACML-based authorization system may be less than adequate.
  • Complexity The complexity of defining and managing XACML policies.

However, current market trends indicate that there are is some motivation for XACML-based authorization systems. This section includes some architectural and implementation details on XACML with an existing XACML engine.

To summarize, XACML describes both an access control policy language, request/response language, and reference architecture. The policy language is used to express access control policies (who can do what, when). The request/response language expresses queries about whether a particular access should be allowed (requests) and describes answers to those queries(responses). The reference architecture proposes a standard for deployment of necessary software modules within an infrastructure to allow efficient enforcement of policies.


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

When we think about a Most traditional authorization system, it would mostly look like as follows:


systems mostly have the following features: 

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


  • Can business managers (who should determine how access controls would be implemented) define and modify different authorization logicslogic?
  • Can we find new IT technicians to manage these legacy systems? Especially when people those who developed the system , have left the organization?
  • Can different authorization logics logic be modified without any source code changes in an a dynamic way?
  • Is authorization system capable for of 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 logic of a legacy system?
  • Can we achieve finda fine-grant grained authorization level without defining large a large number of static combinations?
  • Is Are the authorization systems capable of answering following the questions such as: “Can a user, Bob, transfer X amount from Y current account at 1.00pm?“

As we can understandClearly, the above goals cannot be achieved from a traditional authorization system. However, a XACML-based authorization solution can provide help to achieve all of these goals. This is , because XACML:

  • is a standard which is ratified by OASIS standards organization.
  • is a policy language implemented using XMLusing XML which is an industry standard.
  • supports Attribute Based -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.

-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 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.


  • Policy Enforcement Point (PEP): The system entity that performs access control by making decision requests and enforcing authorization decisions. Basically this 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 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.


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. 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.

The XACML engine of the WSO2 Identity Server has two major components, i.e., PAP and PDP. This The section below focuses on Policy Decision Point (PDP) only.

The following diagram represents the component architecture of the PDP.

The following information provides a more details detailed information on the various components available in the PDP architecture.

Entitlement Admin Service

All PDP configurations have been are exposed via this API as a Web service . You which you need to have certain privilege privileges to access this API. The following functions can be done by calling this API.


Actual XACML authorization API has been is exposed via this API as a Web service. This service supports the following three communication methods with PEP.


This is the core of the engine. Balana PDP has been initialized with all the attribute finders, resource finders and policy finder modules that have been are plugged with WSO2 Identity Server.


This is same as Balana PDP. However, this instance has been initialized with the PAP policy store. It means, policies that are defined by PAP can be evaluated by using this PDP instance. There is no policy caching or decision caching with this. Therefore, this can only be only used for testing your policies in the PAP store. Web service API for Balana Test PDP has been is exposed via the Entitlement Admin Service with method name “doTestRequest()”.


This module finds policies from different policy stores to evaluate a XACML request. The following is a high-level diagram of how this works.


Any number of policy finder modules can be plugged with the Carbon policy finder. You need to implement the CarbonPolicyFinderModule interface to write a new module and register it using the configuration file called configuration file.xml in <IS_HOME>/repository/components/features/org.wso2.carbon.identity.xacml.server_5.8.145 directory. By default, WSO2 Identity Server is shipped with a Carbon registry-based policy finder module that can retrieve policies from a registry collection, where the collection path is configurable using a property value in the configuration .xml file.

All modules would be are initialized and policies would be are loaded into memory when the Carbon policy finder is used. Loaded policies are kept as a policy collection where you can use your own implementation to access them. A written policy collection implementation can be registered using the configuration .xml file. The default implementation uses an in-memory cache and creates an effective policy for a given XACML request.

Therefore, the Carbon policy finder always finds effective policies from the policy collection where it is recommended to be kept in-memory. However, if any update in the policy store happens, the Carbon policy finder can be re-initialized automatically by the module that you have written, or you can re-initialize it by using the Web service API (Entitlement Admin Service). Also Alternatively, you can manually do it manually using the Identity Server Management Console.


This module helps to find the missing attribute for a given XACML request. The following is the high-level diagram for both the Carbon attribute and resource finders.


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.


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


  •  <Rule> -  Element that contains a Boolean 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 -based Access ControlingControlling, in XACML all the attributes are categorized into the following four main categories: But from XACML 3.0, custom categories are also supported.


  • <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 of 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 The 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.


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 instance, lets's say 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 issueeasily. According to the XACML 3.0 policy schema, the category of XACML element is identified by a XML attribute called “Category”. 


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


Improvements in Obligation

In general obligation , obligations can have the following,



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


There are several improvements with Obligation Obligations 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 in-depth understanding, see the following example:

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


Code Block
<Obligation ObligationId="send-email" FulfillOn="Deny">
	<AttributeAssignment AttributeId="email" DataType=""></AttributeAssignment>

However, the user would may 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).


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

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.


In XACML 2.0, the Target element contains the OR and AND relationship between the same category. However, in XACML 3.0, AllOf and AnyOf elements have been introduced to Target element. That clearly helps to define the OR and AND relationship between different categories.

As an example, let's 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 can access the foo resource or do a bar action” by using the Target element.


Some improvements to other functions such as:

  • urn:oasis:names:tc:xacml:3.0:function:dayTimeDuration-equal
  • urn:oasis:names:tc:xacml:3.0:function:yearMonthDuration-equal
  • urn:oasis:names:tc:xacml:3.0:function:dateTime-add-dayTimeDuration