Being part of WSO2 middleware platform, XACML PDP (Policy Decision Point) functionality in Identity Server is exposed as a web service called 'Entitlement Service' whose implementation can be found here.
Describing XACML reference architecture and XACML policy language is out of the scope of this post and you can refer to my previous post to get an overall idea about an example solution based on XACML.
A PEP (Policy Enforcement Point) can consume the EntitlementService through a SOAP based client and invoke its "getDecision" method to obtain the authorization decision for a given XACML authorization request. Such a PEP exists in WSO2 ESB as a mediator called EntitlementMediator.
In this post, I will take you through a simple java client which acts as a PEP.
Describing XACML reference architecture and XACML policy language is out of the scope of this post and you can refer to my previous post to get an overall idea about an example solution based on XACML.
A PEP (Policy Enforcement Point) can consume the EntitlementService through a SOAP based client and invoke its "getDecision" method to obtain the authorization decision for a given XACML authorization request. Such a PEP exists in WSO2 ESB as a mediator called EntitlementMediator.
In this post, I will take you through a simple java client which acts as a PEP.
1) First of all, lets look at the communication flow between a PEP and PDP of IS with SOAP based implementation:
In the above diagram, in addition to the Entitlement Service, there is also AuthenticationAdmin service comes into play in between client and the EntitlementService.
What does it do?
It authenticates the clients against the user store before the client is capable of invoking an AdminService. Any request coming to the back end server is hit by the Authentication Handler (which is an axis2 handler) and if that request is for an AdminService, handler checks whether the request is authenticated.
Now comes the question, what is an AdminService?
Well.. In WSO2 Carbon, we have a concept called AdminService whose charaterisitcs are as follows:
- Can only be invoked by an authenticated user in the system.
- Exposed over secure transport.
Entitlement Service is exposed as an AdminService since it exposes the functionality of obtaining authorization decision and since it communicates security sensitive information.
You can read more about carbon authentication framework from here.
You can read more about carbon authentication framework from here.
2) Before looking at the PEP client code, lets setup the PDP of IS with a sample XACML policy.
Start the identity server->login to management console->access Entitlement -> Administration -> Add New Entitlement Policy
WSO2 Identity Server has a rich XACML UI editor through which you can configure XACML policies easily.
Our XACML policy will enforce following rule: Read access to the resource called 'ABCResource' is only allowed to users belonged to admin role and all the other request to this rersource will be denied.
Please follow the following screen shots to compose the policy through UI editor (If the images are not clear, please click on them to view the enlarged version).
i). Here we define policy name, rule combining algorithm and the policy target.
ii). Next we define the two rules with 'Permit' effect for admin users and 'Deny' effect for all other requests.
iii) We can evaluate the XACML policy by sending a mock XACML request from the 'TryIt' tool provided by the Identity Server as shown below.
In the above request, a user in role 'eng' is trying to read the resource 'ABCResource' which should result in deny effect when evalated against the defined XACML policy.
iv). You can also obtain the exact XACML request created by the above 'TryIt' tool by selecting "Create Request" which you can observe as below.
3) Java client as PEP
You can download the source code of the SOAP based client which can act as a PEP and consume Entitlement Service - PDP of IS, to obtain the authorization decisions.
(Here I have only illustrated how to consume PDP, you can continue implementing a complete PEP who tracks access requests from users, composes XACML requests for those resource access requests, gets them authorized by PDP and responds to users accordingly.)
(Please note that I have trimmed off some of the code segments for the sake of brevity. Please use full source code in the above link.)
public class EntitlementClient { private static String serverUrl = "https://localhost:9443/services/"; //some code goes here //sample XACML request captured from TryIt tool of IdentityServer. private static String sampleRequest = "line07: hard coded XACML request which will be given as input when invoking Entitlement Service. This can be obtained from TryIt tool as described in section 2.iv//actual request is removed for brevity "; public static void main(String[] args) { try { //set trust store properties required in SSL communication. System.setProperty("javax.net.ssl.trustStore", "/home/hasini/WSO2/wso2is-3.2.0/repository/resources/security/wso2carbon.jks"); System.setProperty("javax.net.ssl.trustStorePassword", "wso2carbon"); //initialize authentication admin stub EntitlementClient remoteEntitlementClient = new EntitlementClient(); //login using authentication admin stub providing valid credentials remoteEntitlementClient.login("admin", "admin"); //initialize entitlement service stub with obtained auth cookie remoteEntitlementClient.initEntitlementClient(); //invoke EntitlementService by passing the XACML request and obtain the authorization decision String decision = entitlementServiceClient.getDecision(sampleRequest); //print the authorization decision System.out.println(decision);
line16,18: Being AdminServices, AuthenticationAdmin and Entitlement Service are exposed over HTTPS. So here we need to set SSL system properties. Please change them to suit your environment.
line21-30: You can understand by relating the comments in the code with the communication flow illustrated in secion 1.
Setting up and running the client:
In order to run the client, please make sure you have included the two paths: "[IS_home]/lib/api" and "[IS_home]/repository/components/plugins" into your classpath.
So what?
I hope you got an idea about how PDP in IS is exposed and how to write a custom PEP to consume it and about the communication flow between the two.
In fact this is written to build up the foundation for another post I am going to write in the near future. Stay tuned.. and Have a nice day..!!
Thanx for the post. It really helped...:)
ReplyDelete+1 Great. Searched every where to learn about these things.
ReplyDeleteHi Hasini,
ReplyDeleteThe getDecision function returns a string (either Permit or Deny or Not Applicable).
If the policy had any obligation, then how do we get the obligation in the xacml response. Does WSO2 expose any functions for this.
Kindly reply.
Hi Sumanth,
ReplyDeleteImproved obligation support comes with next release of Identity Server. Please refer the blog: http://xacmlinfo.com/2012/07/12/what-is-new-with-xacml-3-0/ for more info.
Thanks,
Hasini.
Hi Hasini,
ReplyDeleteThanks a lot for your reply. Had one more small query.
Does WSO2 IS expose any api to programatically access xacml policies and modify them i.e. modify the xacml policies thro java code?
Warm regards,
Sumanth Vishwaraj