Enforcing XACML Based Authorization Scheme Using WSO2 Identity Server

XACML(eXtensible Access Control Markup Language) is a standardized dialect of XML from OASIS which is used to enforce authorization policies. XACML allows fine and coarse grained authorization policies, conditional authorization, policy combination and conflict resolution and independent from implementation mechanisms.

The policy language is used to describe general access control requirements, and has standard extension points for defining new functions, data types, combining logic, etc. The request/response based language lets you form a query to question whether or not a given action should be allowed, and interpret the result. The response always includes an answer about whether the request should be allowed using one of four values: Permit, Deny, Indeterminate (an error occurred or some required value was missing, so a decision cannot be made) or Not Applicable (the request can’t be answered by this service). The XACML Fine Grained Entitlement provides a flexible way to limit access to resources based on role, user, time period, environment or any other attribute. For an example of fine grained authorization is to allow users with admin role to access Data Services between 11 AM and 4 PM on weekends.

WSO2 Identity server

In this article I’m using WSO2 Identity Server (IS) to implement the XACML authorization scheme. WSO2 IS provides fine-grained policy based access control via XACML supporting both XACML 2.0 and XACML 3.0 specifications. The most significant factor is the easy-to-understand graphical user interface provided by WSO2 IS to define complex XACML policies in a simple manner. 
 The UI explains itself how it needs to be used and any newbie can learn and at the same time execute the policies with the Tryit option to understand how it works. 
 
 You can download the latest version of WSO2 Identity Server by referring to their product site. I have used WSO2 Identity Server 5.3.0 which is the latest stable version as per the time of writing this article. Once you download it extract it and start the server using the following command (linux).

sh $PRODUCT_HOME/bin/wso2server.sh

Here, $PRODUCT_HOME is the location where the server was extracted.
 Once we start WSO2 IS and go to management console at http://localhost:9443/carbon, the default URL and you have to give credentials (user name:’admin’ and password: ‘admin’). You will be able to see the following interface if login was successful.

In main menu under entitlement tab click on policy administration.

Home> Entitlement> PAP> Policy Administration

This window gives us the option to create and define new policies, edit them and enforce policy combination algorithms. You can also see some pre-defined policies as well. Click on any of those policy names to see their source view. We have the capability to import XACML policies as XML files and also we can define policies via the UI which will be much easier.
 
 In order to create a new policy simple click on ‘Add new entitlement policy’. Which specifies some of the policy creation editiors in WSO2 IS that we can use. We will use the standard policy editor. Using this you can create a normal XACML 3.0 policies with defined custom categories, attributeIs and DataTypes. Also you can add Obligations and Advices in to your rules and policy.
 
 Once you click on standard policy editor it will direct you to the policy creation window which provides you with the facility to create XACML policies by simply choosing conditions from the UI itself. 
 
 Here we are going to create a new XACML policy which simply grants authorization to any user with the admin role privileges and denies all other users who tries to log into the application with WSO2 IS configured as their Identity service provider(IDP).

Entitlement Policy Name: this can be any name applicable to the policy you are defining. I am using ‘travelocityAuthzByAdminRole’ as policy name since my entitlement policy is to provide admin grant on travelocity application.

Here we will use first applicable as the rule combining algorithm. Through this algorithm the final decision of evaluating the rules is based on the evaluation results of the first rule that produced either of permit or deny. 
(there can be intermittent state for rule evaluations as well) . The following link provides more details on XACML’s rule combining algorithms. 
 
https://www.axiomatics.com/blog/understanding-xacml-combining-algorithms/

Thereafter we have to define the conditions that should be matched in order to use this policy for evaluations by IDP. Ideally since we are enforcing authorization this policy should be evaluated when a user tries to authenticate themselves at the IDP. In addition to that we have to define to which service provider this policy should be applicable. This can be any of the service providers we have configured under Main > Service Providers > list section. Also you can create a new service provider with WSO2 IS configured as its IDP and add this authorization policy to that service provider.

Here the term service provider refers to any external application that provides and implements the web service and makes them available on the Internet. We can use WSO2 IS configured with those Service Providers to handle user authentication and authorization. When we enable this facility whenever a user tries to login to that application, he will be redirected to WSO2 IS login page which handles all the user management functionalities. 
 So, the conditions should be ;

ServiceProvider is equal travelocity AND Action is equal authenticate

After defining the conditions for the policy to be evaluated, we need to define entitlement rules. 
 
Rule name: adminGrant
Rule effect: Permit
 
 Rule’s condition should be IdentityUser is equal admin

Click the icon indicated by 1 to select attribute values of the subject. We need to specify the attribute ID as role and attribute data type as String.

After adding the role attribute value click on add(2) to add this rule.
 
 Now we have added an entitlement rule to grant access to a user if his role is admin. But in addition to this we have to add another rule which will deny any other user. That means non-admin users will be denied of access to the application.
 
 Click on define entitlement rules to add another rule
 
 Rule name: DenyOthers
 Rule effect: Deny
 
 Here we do not need to add additional conditions since we are denying access to all the other users except for the admin.
 After adding the rule click finish to complete policy creation.

If everything was added correctly you will get the following message.

Now you will be able to see the rule you created under available Entitlement policies in Policy Administration.

As the next step in order to use this policy for evaluations on user authentication flows we have to publish the policy to the PDP(Policy Decision Point). Simply click on Publish to my PDP option on the newly created entitlement policy. And click on publish.

If your policy was published successfully, under the PDP > policy view section you will be able to view the policy you created. 
 
 In the PDP view section you have the options to enable/disable your policies, create, delete and give the order of executions (policies with higher orders will be evaluated before the policies with lower orders) for these policies.

This is the source view of the policy we just created.


XACML Policy

<Policy xmlns=”urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" PolicyId=”travelocityAuthzByAdminRole” RuleCombiningAlgId=”urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable” Version=”1.0">
<Target>
<AnyOf>
<AllOf>
<Match MatchId=”urn:oasis:names:tc:xacml:1.0:function:string-equal”>
<AttributeValue DataType=”http://www.w3.org/2001/XMLSchema#string”>travelocity</AttributeValue>
<AttributeDesignator AttributeId=”http://wso2.org/identity/sp/sp-name" Category=”http://wso2.org/identity/sp" DataType=”http://www.w3.org/2001/XMLSchema#string" MustBePresent=”true”></AttributeDesignator>
</Match>
<Match MatchId=”urn:oasis:names:tc:xacml:1.0:function:string-equal”>
<AttributeValue DataType=”http://www.w3.org/2001/XMLSchema#string">authenticate</AttributeValue>
<AttributeDesignator AttributeId=”http://wso2.org/identity/identity-action/action-name" Category=”http://wso2.org/identity/identity-action" DataType=”http://www.w3.org/2001/XMLSchema#string" MustBePresent=”true”></AttributeDesignator>
</Match>
</AllOf>
</AnyOf>
</Target>
<Rule Effect=”Permit” RuleId=”adminGrant”>
<Target>
<AnyOf>
<AllOf>
<Match MatchId=”urn:oasis:names:tc:xacml:1.0:function:string-equal”>
<AttributeValue DataType=”http://www.w3.org/2001/XMLSchema#string”>admin</AttributeValue>
<AttributeDesignator AttributeId=”http://wso2.org/claims/role" Category=”urn:oasis:names:tc:xacml:1.0:subject-category:access-subject” DataType=”http://www.w3.org/2001/XMLSchema#string" MustBePresent=”true”></AttributeDesignator>
</Match>
</AllOf>
</AnyOf>
</Target>
</Rule>
<Rule Effect=”Deny” RuleId=”denyothers”></Rule>
</Policy>

Sample XACML request to evaluate the policy(Can be used with the TryIt tool)

<Request xmlns=”urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" CombinedDecision=”false” ReturnPolicyIdList=”false”>
<Attributes Category=”http://wso2.org/identity/identity-action">
<Attribute AttributeId=”http://wso2.org/identity/identity-action/action-name" IncludeInResult=”false”>
<AttributeValue DataType=”http://www.w3.org/2001/XMLSchema#string">authenticate</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category=”urn:oasis:names:tc:xacml:1.0:subject-category:access-subject”>
<Attribute AttributeId=”http://wso2.org/claims/role" IncludeInResult=”false”>
<AttributeValue DataType=”http://www.w3.org/2001/XMLSchema#string">admin</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category=”http://wso2.org/identity/sp">
<Attribute AttributeId=”http://wso2.org/identity/sp/sp-name" IncludeInResult=”false”>
<AttributeValue DataType=”http://www.w3.org/2001/XMLSchema#string">travelocity</AttributeValue>
</Attribute>
</Attributes>
</Request>