XACML is the standard for access control in the SOA. But it seems to be that it is still not much widely adopted within the enterprises yet. I guess, mostly people may not have an idea about the capability of the XACML… It just not a XML based policy language… It has lot of extensibility that can be used in different use cases. Today.. I am going to show you how we can define access control policies for a web application using XACML.
Lets take an example, Assume that there are three web pages in the web application. When end user travels through this web application, user is needed be authorized and user only can be viewed only the authorized items in these three pages. Basically web application needs to filter out the authorized resources/actions for given user. This is a typical use case that we found with XACML. This would become more popular with XACML 3.0 due to multiple decision profile. With multiple decision profile, web application (PEP) can ask authorization for multiple resources/actions from the XACML engine (PDP). And PEP can only filter out the permit results.
However with WSO2 Identity Server, there are four ways that you can implement this.
1. Multiple Decision Profile with repeated attribute categories.
Web application (PEP) must send the list of resources/actions that web application contains and the user name who is going to access these resources/actions. Typical if there are more pages in the web application, when user travels to each page, XACML request can be generated with the resources/actions that each page contains. PDP returns the decision with resources/actions. Then it is shown only the permitted resources/actions for users. Sample on this can be found at here
2. Multiple Decision Profile with hierarchical resource profile.
This is same as the repeated attribute categories. But web application (PEP) does not need to send all resources that web page contains. PEP would send only the root resources. PDP knows how to extract the child resources corresponding to root resources. Child resources are extracted from an extension point where it can be customizable according to use case. Sample on this can be found at here
3. “getEntitledAttributes” method in Identity Server.
This is not the standard way of doing this and this is specific to Identity Server. Once user login to web application, web application can call to “getEntitledAttributes” method and can retrieve the entitled resources for given user. Here you do not want to do much things as data would be extracted from the defined XACML policies. Sounds Great…!!!
But as i mentioned in my previous post. This is not a effective way and this would not works for complex policies. Therefore it is recommended go with this approach, if there is no any other options.
4. “getAllEntitlements” method in Identity Server.
This is also same as the “getEntitledAttributes”method. But “getAllEntitlements” method contains more flexibility than the previous. We can pass multiple attribute as input parameters.
Try out the Scenario
To understand above four implementations better, Let go though sample scenario. Just assume that there are three pages in the web application and each of them contains following actions.
view-welcome view-summary view-status modify-welcome modify-summary
view-apps search-apps add-app delete-app edit-app
download search add remove
Lets create following use case.
1. There are an index.jsp, configure.jsp and download.jsp pages that can be accessed after the user login in to the web application.
2. There are three user groups called “publicUsers”, “internalUsers” and “adminUsers”
3. “publicUsers” are the users who has registered to view the contain of the web site. And they are only allowed to perform view-welcome, view-summary download and search
4. “internalUsers” are the internal users of the organization, They area only allowed to what publicUsers can do and also view-status, view-apps and search-apps
5. “adminUsers” are internal admin users of the organization, They can view any images.
XACML Policies and PIP
For this scenario, we are hoping to use LDAP user store which is embedded with the WSO2 Identity Server. But it can be any LDAP or AD or JDBC user store. Once user store is connected with Identity Server, You can manage users and roles in the LDAP user store using Identity Server management console.
Lets try to create users and roles. You need to create roles called “publicUsers”, “internalUsers” and “adminUser” And you can create users and assign to these roles.
In next few blog post… We are going to try out this sample scenario with above four ways.