Authorization is a key aspect of identity management and security in enterprise applications. There are various access control mechanisms such as
There are drawbacks in these mechanisms such as non-scalability, coarse-grained permission and authorization logic being coupled with application logic which prevents flexibility. Policy-Based Access Control on the other hand is emerging as a flexible and scalable solution for access management. XACML is a powerful way of achieving PBAC in a fine grained manner.
Image 1: Solution Architecture
Setting up the Solution
1. Hosting the back-end service:
Image 2: Hosting the service in Application Server
2. Setting up WSO2 Identity Server (IS):
This plays the roles of PAP, PDP and PIP in our solution as mentioned above.
Image 3: Policy administration in Identity Server
3. Setting up WSO2 ESB as PEP:
Image 4: Configuring ESB proxy service
Remarks On Proxy Service:
Please note the following configuration of the proxy service (just like what is shown above, which authenticates the user), obtains the authorization decision by communicating with IS and allows/denies access to back-end service.
Running the Client
Let us have a look at our sample client code, (which you can download from here) which invokes the RESTful back-end service which is secured by ESB proxy service.
Here I need to highlight the REST way of invoking the proxy service when it is secured with User Name Token security policy.
Following is how we perform the subsequent operations on the service stub.
As you can see, we perform “add student” operation as admin user and “get student” and “update student” operations as a non admin user. According to the scenario we mentioned at the very beginning, only the first two operations should be successful and the third operations should be denied.
Since the first and the third operation are asynchronous, we can not observe whether the operation was allowed or denied from client side. To observe that, you need to enable debug level log for entitlement mediator in ESB.
Steps for running the client:
When you run the client, you will observe that “add student” operation and “get student” operation will pass and the “update student” operation will be denied (please refer to ESB logs) based on the user who invokes the operation and the defined XACML policy.
In this way, you can achieve fine-grained access control with PBAC solutions with XACML. Although this sample incorporates users' role as the attribute to define access control rules, you can use other attributes as well and manage access to your enterprise resources in a fine-grained manner.
I believe you got an overall idea of how to build up an access management solution with XACML using WSO2 products stack. Next, let’s go through the XACML policy used in this sample and the XACML requests sent to PDP in order to discuss how authorization decisions are taken. Let me begin by stating the authorization policy that we needed to enforce:
Allow access for admin users to perform all - POST, PUT ,GET and DELETE operations of the service (since three of the methods do modifications in the system) and allow access to GET method to all the users in 'admin' and 'everyone' roles.
Following is how XACML defines above mentioned authorization policy: (you can obtain it from here as well)
Well, it might not be convincing at 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.
3. 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.
4. 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.
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 consists of:
You can get a good understanding about XAML requests from the post: Anatomy of the XACML request
1. When admin tries to add a student:
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:
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:
Above request will be denied since there is no rule defined with the effect of 'permit' that matches it. Hence it will be denied by the default deny rule.
This concludes the explanation on how to build up an access management solution with XACML using WSO2 product stack and also how the XACML policies and requests involve in taking authorization decisions.