Fine grained authorization to RESTful services with XACML - Part II

We are going to look into the XACML policy and the XACML requests involved in the sample that I described in Part I, and analyze how the authorization decisions we observed in Part I were derived.

Let me state in english the authorization policy that we needed to enforce...

Allow access to perform all - POST, PUT ,GET and DELETE operations of the service only to admin users (since three methods do modifications in the system) and allow access to GET method to all the users in 'admin' and 'everyone' roles..

XACML Policy
Following is how XACML defines above mentioned authorization policy: (you can obtain it from here as well)

  
    
      
    
    
      
        
          http://localhost:9766/services/RestService
          
        
      
    
    
      
    
  
  
    
      
        
          
            admin
            
          
        
      
    
    
      
        
          
            http://localhost:9766/services/RestService/POST
            http://localhost:9766/services/RestService/PUT
            http://localhost:9766/services/RestService/DELETE
            http://localhost:9766/services/RestService/GET
          
          
        
        
          
            POST
            PUT
            DELETE
            GET
          
          
        
      
    
  
  
    
      
        
          
            everyone
            
          
        
      
    
    
      
        
          
            http://localhost:9766/services/RestService/GET
          
          
        
        
          
            GET
          
          
        
      
    
  
  

Well.. it might not be convincing in the first glance. Let us look at it step by step.

  1.  Policy is consisted of a target and a set of rules. Information in the target element is used by the PDP to pick a matching policy for an incoming authorization request, out of many policies available in the PDP. Then the request is evaluated against the set of rules defined in the policy.
In our case, above policy will be picked for any request whose "Subject" element matches the regexp : http://localhost:9766/services/RestService

  2.  Above XACML policy has three rules defined: 

• "admin_allow_rule": defines which operations to resources are allowed to users in admin role.
• "everyone_allow_rule": defines which operations to resources are allowed to users in everyone role (In carbon products, all the users are belonged to everyone role by default.).
• "deny-rule": defines that requests come in any other criteria should be denied.

   2.  Rule combining algorithm used in the above policy is "first-applicable" which means that the first rule that evaluates to true will take effect and others will be ignored.

   3.  A rule is consisted of a target and a set of conditions. Rule element has two parameters: rule-id and effect-which specifies the outcome of the rule if given conditions are met and the target is matched.

Rule conditions are useful when the target can not express the constraints adequately.

In our policy, the two rules have targets specifying for which subject type the rule should be evaluated for. In the first rule, its the subject of role type 'admin' and for the second rule, it is the subject of role type 'everyone'.

There is a series of blog posts by Prabath which will help you to master on writting XACML policies.

XACML requests

Now let us have a look at the XACML requests sent by PEP (ESB) to the PDP (IS)

for the three requests sent by the client to access the back-end service.

(You can observe the XACML request at the Idenetity Server back-end if you enable debug level logs for the Entitlement Service in IS.)

A XACML request is consisted of:

• Subject - defines attributes of the entity who tries to access the resource
• Resource - defines the resource that is being accessed 
• Action - the action that is being performed on the resource.

You will be able to get a good understanding about XAML requests from the post: Anatomy of the XACML request

1. When admin tries to add a student:

admin


http://localhost:9766/services/RestService/POST


POST

The above request will be evaluated to true by the first rule in the above XACML policy since it matches the target and the conditions.

2. When non-admin user tries to get student:

hasini


http://localhost:9766/services/RestService/GET


GET

Above request will be evaluated to by the second rule defined in the policy which allows all the users in admin and everyone role to allow access to GET operation.

3. When non-admin user tries to update student:

hasini


http://localhost:9766/services/RestService/PUT


PUT


  

Above request will be denied since there is no any rule defined with the effect of 'permit' that matches it. Hence it will be denied by the default deny rule.

Well..from the series of these two blog posts, I hope you got an understanding about how to build up an access management solution with XACML using WSO2 product stack and also about how the XACML policies, requests involve in taking authorization decisions.

I would like to thank Prabath, Thilina, Asela and Amila Suriarachchi for the help in gaining knowledge in the area and getting the end to end sample working.