XACML with WSO2 Identity Server
Photo by Martin Olsen on Unsplash
What is XACML?
According to Wikipedia, “XACML stands for “eXtensible Access Control Markup Language”. The standard defines a declarative fine-grained, attribute-based access control policy language, an architecture, and a processing model describing how to evaluate access requests according to the rules defined in policies.”
The definition is pretty much clear. We are not going to discuss about the architecture and terminology in this post. If you want to understand the architecture of XACML in more detail, there are already plenty of great articles on INTERNET. I will provide the list of few at the end of this post.
In this post we will see how we can create a sample XACML policy and use it in applications to achieve fine-grained access control. Also, I am going to demonstrate how WSO2IS has made it extremely simple to define and manage XACML policies and has an extremely fast XACML engine to evaluate the XACML policies against XACML requests. So let’s get started.
Create a simple XACML policy
First thing first, we have to define an XACML policy. XACML policies are defined in XML. But no one wants to write complicated XML. WSO2IS to the rescue. If you do not know about WSO2IS, read it here. So before we continue, make sure you have downloaded the latest version of WSO2IS (it is free!!) from the official website and it is up and running. Open the management console (https://localhost:9443/carbon/admin/login.jsp) and login with default admin user (admin:admin).
Admin Console of WSO2IS
Click on “Policy Administration” in the left menu under “Entitlement”. Here you can see that WSO2IS has already defined several predefined XACML policy templates to help us. Good job WSO2IS team. For now we will focus on creating a new policy.
Policy templates provided by WSO2IS
To define a new policy, click on “Add New Entitlement Policy” and choose one of the GUI editor provided by WSO2 to create a new policy. Lets, try “Simple Policy Editor”. Click on it, and let us move to the next section.
Policy Editors in WSO2IS
Scenario
Let us consider a very basic scenario where we want to protect an URL “/api/users/” that we will refer as resource. We want that only users having role “admin” can make a POST request to this URL. We will refer this POST request as action. All other roles must be denied to make POST request to this resource.
Enter following details in the screen and click Finish.
Simple Policy Editor
Congratulations! you have created your first XACML policy without even writing a single line of XML, all from a simple UI.
Understand the generated XML
Click on the newly created policy to see the policy definition in XML. The XML has two main sections, Target and Rule. The “Target” part as highlighted in the above image defines the condition for which this policy will be evaluated. In our case, the XACML request must have a parameter “resource-id” with value “/api/users/”. If the this condition is not satisfied, the policy engine will not consider this policy to evaluate when it will receive the XACML request. This is great, because it will help the policy engine to response fast as it will not evaluate each and every policy defined in the policy engine.
The next part is “Rule”. In this part we can define multiple rules. Each “Rule” has its own “Target” and “Condition”. In our case, we have created a rule that will be evaluated if the XACML request will have parameter “action-id” with value “post”. And this rule will return **true **when XACML request will have parameter role with value “admin”.
That is enough for now to understand the XML structure of the policy. Let us continue and see how we can make use of this policy.
Publish the policy
So far we have successfully created a policy, but it is not ready to use. For that, we have to publish the policy to PDP (Policy Decision Point). Follow the below steps to do that:
Evaluating the policy
WSO2IS allows us to send the XACML request as JSON or XML. Let us create a JSON request. We will use Postman to send XACML request to PEP (Policy Enforcement Point). Enter following details in Postman:
URL: https://localhost:9443/api/identity/entitlement/decision/pdp
*Body: *{“Request”: {“AccessSubject”: {“Attribute”: [{“AttributeId”: “http://wso2.org/claims/role","Value": “user”,”DataType”: “string”,”IncludeInResult”: false}]},”Resource”: {“Attribute”: [{“AttributeId”: “resource-id”,”Value”: “/api/users1/”,”DataType”: “string”,”IncludeInResult”: false}]},”Action”: {“Attribute”: [{“AttributeId”: “action-id”,”Value”: “post”,”DataType”: “string”,”IncludeInResult”: false}]}}}
Authorization:
Pay attention to the highlighted parts.
In the above request, we are sending the information about the Resource, **Action **and a attribute of **Subject **i.e. Role. If you remember, we used these three parameters to define our XACML policy. Let’s send the request and analyze the response.
We have received the following response:
Postman Response Not Applicable
Notice the “Decision” parameter. We have received “NotApplicable” because we sent “/api/users1/” (check the Body) and our request is not matching with “Target” of any published policy. Let us change the value of resource to “/api/users/” and send the request again. This time we have received following response:
Request Denied
This time we have received the Decision as “Deny”. This is because we have sent “user” (check the Body) as role, and the Rule in the XACML policy is expecting “admin”. So this user with role “user” is denied to make POST request to resource “/api/users/”. Let’s change the role to “admin” and send the request again. Now we have following response:
Request Permitted
Tada! We have received “Permit”. It means, the request has fulfilled all conditions in the policy and we can allow this request in the our application. Now when we know how easy it is to define and evaluate the XACML policies in WSO2IS, let’s discuss about some use cases.
Use Cases
Here are few use cases of XACML policies.
Use XACML as ABAC (Attribute Based Access Control) in any application irrespective of technology. For example, you can create a filter in your spring boot application that will invoke PEP every time when it receives the request. Thinking about extra network call for each request? Well, you do not need to protect each and every resource. For example, anyone can see the list of users (GET) but only “admin” can make the update (POST) request. So no need to invoke the policy engine for GET requests. This will avoid unnecessary network calls.
Use XACML in the authentication flow of WSO2IS to restrict the user based on attribute, role, time etc. For example, in WSO2IS you can use XACML policy to restrict users to take login in the application on weekend. Cool.
Enable guest accounts, for more details refer this: https://medium.com/identity-beyond-borders/how-to-enable-guest-accounts-in-wso2-identity-server-af17b2ca7b2c
Performance
There is a nice article from WSO2 team that explains how the performance can be improved with help of cache: https://is.docs.wso2.com/en/latest/learn/improving-xacml-pdp-performance-with-caching-techniques/
Another article discuss about the performance test done by WSO2 team: https://docs.wso2.com/display/IS570/XACML+Performance+in+the+Identity+Server
Architecture,Pros n cons
There is a nice article about this.
Merry XACML and Happy Access Control!
*I know it’s a bit late for this, but It’s better late than never! :D*medium.com
In the next post, we will create some more advance XACML policies and will see some advanced use cases. We will also integrate the XACML with Spring Boot.
I will be writing more on XACML, WSO2IS, Angular, Spring Boot, AZURE, AWS etc. Do leave your feedback in the comments. If you liked this post, click on claps and follow me to see more stuff on above mentioned topics.
Stay Home, Stay Safe.
Top comments (0)