Friday, March 25, 2016

WSO2 Identity Server : Understanding XACML 3.0 policies, implementing them in IS and testing with SoapUI

Hi folks,

This is a weird way to resume a blog that was silent for a long time. But I guess this will do. The reason for this post is mainly GSoC 16' which is currently happening. And in selecting a project for it, I came up with WSO2 which has middleware based products. And with time constraints, I was forced to study a system overnight and thought that documenting what I found would be beneficial for those who try to do the same later.

So the question here is what exactly WSO2 Identity Server does?

WSO2 Identity Server (IS) is an identity management system based on open standards. It's a middleware that would connect all dispersed authentication services you have into one manageable system. It has many features that makes authentication and authorization of users for your resources a simple and efficient task. Since the scope of this post is not explaining what IS is, I recommend you to follow the following links to have a better idea. (Dear future GSoC applicant, it is very important that you go through those seemingly boring but highly important links :) )

Get to know the high level artichecture

A very simple getting started guide

The blog that would contains answers to many questions on IS

Now since you have some idea about IS, let's dig into XACML specification, its uses and how IS has implemented it.
XACML is set of standards by OASIS that are related to access control. In general, it specify a way or a language through which applications should communicate to request authentication and authorization data from eachother. Since the specification in discuss is XACML 3.0, from the following link you can observe how a XACML document would look like.

So why XACML is important to Identity Server is:

  1. It is used as the request/response language standard
  2. It is used as the access control policy standard

With that we get the question what exactly is a policy? and how is it all related?

Okay, let's take some theory in.
A policy (in this context) is a set of rules that would define to IS who can access what. Basically its like a paper from a rule book, Whenever someone asks if a user "A" can perform action "WRITE" to the resource "R", it will go through those policy pages and see if there's any policy defining those requirements.
Let's see the above explanation in a more technical way.

Assume there's a resource link. Whoever accessing the resource now would meet a blocker before the actual resource end point. This blocker is known as the Policy Enforcement Point (PEP). The PEP is like the guardian of the front gate that would catch the request and it wants to know if the requests comes from a client that actually has access to the resource. For that it sends the request data to a place called Policy Decision Point (PDP). PDP is like the rule book reader that matches requests data against any rules in the rule book. The rule book is known as the Policy Administration Point (PAP), it is where all the policies are written.
Additionally there's a component known as Policy Information Point (PIP). This is a place where the PDP can ask for more information of a user that's requesting the authorization.

Now the three parts PIP, PDP, PAP are working together to figure out if the request can pass through the blocker (PEP) and reach the resource. It can do so only if they given the 'Permit' flag back as response to the PEP. If you look at the following diagram things may get more clear.

[Well just looking won't help, you have to really try to understand]

XACML architecture implementation in IS

I think that actually clears-up the theory part. So we can now get into real action :D


Suppose there's a resource located at
And this service should only be accessed by admins (Or any user that is given the user role as 'admin')

1) Configure IS to have a policy to support the above rule
2) Validate the policy using the IS inbuilt Try-it feature
3) Use SoapUI to simulate a PEP that is sending a SOAP request to check if a potential user is can access the given resource

1) WSO2 Identity Server downloaded / build from source
2) SoapUI (free version would do)


1) Adding a policy to IS
Download and Start the Identity Server (Please read above links again if you have idea how to do that)
Login as username ; admin, password: admin
Goto Policy Administration -> Add New Entitlement
Note that entitlement is adding a new policy or a rule to the rulebook
Select Write Policy in XML from the list

2) Writing the policy
Now that there's a windows where we can write our policy in XACML format. We can also use their inbuilt editors, but for the scope of this we'll stick to the text editor.
Use the following policy code. paste it there and click Save Policy

A above policy defines a set of rules,
i) The policy has the id 'auth_admin'
ii) It matches the attribute resource to
iii) It matches the action to exactly be 'read'
iv) It matches the group of the user accessing to exactly be 'admin'

3) Testing the policy
Once you add the policy and save you will see it in the Policy Administration list. From the list there select Try
A new UI would open and select 'Create Request using Editor'
What we going to do here is to create a sample request that might be coming from an actual PEP and test it against our PDP to see if it's working.
Use the folloing xml code, which is a XACML request.

Now click Test Evaluate and you would see that the XACML response appear with the decision tag saying 'permit'. ta-daa! We have successfully made a working XACML policy in IS. Now try changing things in the request, like group name, and resource location and observe the response.

Finally we have to actually put the policy to working mode. This is done by publishing it.
Go back to Policy Administration and publish auth_admin

4) Simulating the PEP using SoapUI
Although we evaluated the Policy using the internet tools, we need to verify that it works from outside too. On the other hand, it is important to observe the response from IS to a PEP using SOAP.
We first need to prepare the IS to show the WSDL definition for SoapUI to extract all endpoints.

Open <product-home>/repository/conf/carbon.xml

Restart IS and navigate to, https://localhost:9443/services/EntitlementService?wsdl
You can see all the endpoints

Open SoapUI and add new project, then add wsdl and put the above url. Once entered you would see that SoapUI automatically identify the endpoints and the service names.
Goto getDecision and right click -&gt; add request
Use the following XMLto have a request

Now we have to put a XACML request INSIDE the SOAP request. In order for the 2 xmls not to fight with each other, we put the XACML request inside CDATA tag, which would prevent it from considering as XML, but it would still be a part of the request text.

Before sending the request we need to add authentication of course.
So add auth from SoapUI and of course put username:password as admin:admin
And hit SEND button. [That green triangular button]

And you would see a SOAP response, in which a CDATA section has the actual XACML response saying 'permit'

So this has been a very long post, and i hope to upload and fix issues here and there in this. But hope this helps.


1 comment: