Implementing RBAC and ABAC with XACML

Let see how we can implement RBAC and ABAC with XACML. Here i am using the well known XACML 3.0 open source engine; Identity Server which is based on Balana.

Lets think about an API access control scenario as following

Think, an API called /patient ( in Health care system.

There are three roles are in system. i.e Patient , Physician and Administrator roles.

Lets defined an access control rules for the system based on roles.

  • Any registered patient can access /patient API with GET (Users in Patient role can do only read access operations on patient API )
  • Any registered physician can access /patient API with GET, POST and PUT (Users in Physician role can to do read, write and update operations on /patient API )
  • Administrator can access /patient API with POST and DELETE (Users in Administrator role can to do create and delete operations to /patient API )
  • All other requests must be denied.

Before creating XACML policy let see, Why it is easy to implement RBAC with Identity Server?

How does Identity Server store users, user’s attributes and user’s roles ?

Identity Server can be connected with any existing user store (LDAP, AD, JDBC with custom schema) in your Enterprise. Or less, we can uses the user store that is shipped with Identity Server.

Identity Server ships two user stores by default

  1. Embedded Apache DS user store. (By default this has been enabled in user-mgt.xml file)
  2. JDBC based user store (You need to enable this using user-mgt.xml file)

Also, Identity Server contains Internal Role store. This is JDBC store and only roles can be created there. These roles are referred to as internal roles.

If identity Sever is connected with an existing user store (or is used to default user stores); Users, User’s attributes and roles are read from the user store. Normally user store has groups and users have been assigned those groups. Identity Server map each user store group in to a role. Therefore all the groups in the user store would be taken as roles by the Identity Server. Also, you can create internal roles and assign users in the user store in to these internal roles.

How can XACML Engine refer roles and user’s attributes ?

Identity Server has concept of claim management that each user’s attributes and user’s roles can be mapped in to unique entity called claim. This provides an easy abstraction layer for other systems to deal with user attributes. I am recommending for you to read this to get more understand about claim management in Identity Server.

Therefore XACML engine can refer the user’s attributes and user’s roles as claims. As an example, Following uri is used to identify the roles of the user.

But you can add/edit/delete these claim mapping as you like using claim management. Let me introduce some morew default claim uris…

  • Email of the user –>
  • Mobile of the user –>
  • Country of the user –>

But there are more in the claim management…

How does RBAC/ABAC Policy look like in XACML ?

Lets go to the example again and take an one access rule as following

If it is action POST for resource /patient, It can be done by users in Physician and Administrator Roles

We can indicate as follows….

if ( action == POST & resource == /patient ) 
                  If ( Role == Physician || Role == Administrator) 
                              return true;

XACML also have many methods and conditions that help to implement above simple authorization checks. Following is the sample XACML rule for this.

<Rule Effect="Permit" RuleId="Rule">
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">
<AttributeValue DataType="">/patient</AttributeValue>
<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" DataType="" MustBePresent="true"/>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="">POST</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"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="">Physician</AttributeValue>
<AttributeValue DataType="">Administrator</AttributeValue>
<AttributeDesignator AttributeId="" Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" DataType="" MustBePresent="true"/>

Important is the, AttributeDesignator element contains following claim uri as the AttributeId,

Which means that user’s roles must be extracted to evaluate the rule. User’s role must be extracted from the XACML request or PIP. (You must read this to get more details on how it is extracted)

If AttributeDesignator element contains following following claim uri as the AttributeId,

It means that user’s email address must be extracted from XACML request or PIP.

Default PIP of the Identity Server is connected with the its own user store. Therefore PIP knows to read the correct attribute of the user which is given by the claim uri

How does RBAC/ABAC Request look like in XACML ?

Think, there is an access request for /patient API resource and access method is POST and the user that accesses the resource is Alice.

Then authorization query for the XACML PDP from the application level (PEP) would be following

Can Alice access the API resource with POST action ?

Therefore, sample XACML request to PDP would be as follows

  • XACML Subject in the request –> Alice
  • XACML Resource in the request —>
  • XACML Action in the request —> POST

Sample XACML request

<Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" CombinedDecision="false" ReturnPolicyIdList="false">
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" IncludeInResult="false">
<AttributeValue DataType="">POST</AttributeValue>
<Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" IncludeInResult="false">
<AttributeValue DataType="">Alice</AttributeValue>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" IncludeInResult="false">
<AttributeValue DataType=""></AttributeValue>

When this request is hit with the PDP, PDP needs to find the Alice’s roles or Alice’s attributes to evaluate the XACML rules. But roles or attributes can not be found in the XACML request.  Therefore PDP calls the PIP for reading user’s roles or user’s attributes

Try out the Sample

Step 1. Let start a fresh Identity Server

Step 2. We can create users and roles (groups) using Identity Server management console or APIs

Lets create,

  • Bob user who is assigned to Patient role
  • Alice user who is assigned to Physician role
  • Peter user who is assigned to Administrator role

Step 3. Lets try to create a simple RABC policy using XACML.

We are is going to defined a XACML policy for API resource called /patient. Therefore we can take the API resource name matching as the XACML Policy Target. Basically If there are multiple policies in the XACML PDP, This XACML policy would be evaluated, when an authorization check query is done for API resource /patient.

Then we need to define the rules for APIM resource /patient.

We can write rules based on the Actions, i.e GET POST PUT and DELETE

  • Rule 1 – If it is a GET, It can be done by users in Physician and Patient Roles
  • Rule 2 – If it is a POST , It can be done by users in Physician and Administrator Roles
  • Rule 3 – If it is a PUT , It can be done by users in Physician Roles
  • Rule 4 – If it is a DELETE , It can be done by users in Administrator Roles
  • Rule 5 – All deny rule.

Also, if you can like you can write these rules based on the role as well such as following

  • Rule 1 – If users is in Patient, GET can be done
  • Rule 2 – If users is in Physician, GET POST PUT can be done
  • Rule 3 – If users is in Administrator, POST DELETE can be done
  • Rule 4 – All deny rule.

Identity Server provides policy editors that you can create these policies very easily. Lets create then using Simple Policy Editor. More details on policy editor can be found from here

Following are the two screen shots for above two approaches.

Approach 1

Approach 2


Step 4. You can policy the created policy in to PDP and You can try it using the simple try it tool.


Thanks for reading….!!!

Discuss this article on Stack Overflow


  1. I am trying Sample 1 , Sample 2 both are working in WSO2 Identity server Version 5.0.0,but how to use these policies in any application please provide any simple sample examples

Leave a Reply

Your email address will not be published. Required fields are marked *