Author: Asela

Searching entitlements in XACML Policies – GetEntitledAttributes

Posted on by Asela

In my previous post, we went though defining XACML policies for web application. Now i am going to try out the scenario, that is defined in that blog post, with third approach. i.e. By using “getEntitledAttributes” method in Entitlement Service API of Identity Server.   Identity Server is an open source XACML engine that supports XACML 3.0.  “getEntitledAttributes” is a method which can be used to retrieve entitled attributes for given user or role. This API method is specific to Identity Server and you can read more details about this from here

Step 1.  You need to upload and publish these policies in to the XACML PDP as enabled policies. You can find more details from here.

Step 2. Use PEP Search tool to invoke the PDP (Or else you can invoke “getEntitledAttributes“ method of the PDP web service API using a SOAP client such as SOAP UI )

Here i am going to retrieve entitled resources for given user called “asela” that has been assigned to “InternalUsers” role

search1

Step 3. You can see the entitled attributes values. i.e resources and actions names.

search2

As mentioned in my previous blog post,  This is not an efficient API method.  Due to two reasons, If i summarized them again

  • This method internally creates all possible XACML requests and they are evaluated with PDP.
  • Attribute values are retrieved by parsing policies to create XACML requests.

In this scenario, As we know the actions set that is related to each web page, Therefore we can feed the action set in to the PDP. Then PDP does not want to extract attribute values from XACML policies and also It can be avoided the creating of some unwanted XACML requests. There is a method that you can extend to feed attribute values that you wish

You can find the sample implementation from here that is an extended version of default policy finder module. Here  “getSearchAttributes”  has been extended to feed the resource and actions names You can try out this scenario with this implementation.  Please go through following additional steps. Here i have found that, number request that have been created internally is reduced by half. With default implementation,  If was around 61 XACML requests and with sample implementation it is 32 XACML requests. That is some improvement. Also It is not parsing XACML policies which is also good for performance.

Step 1. Write a New Policy Finder module by extending the default “RegistryPolicyStoreManageModule”.  Please find the “SamplePolicyAttributeRetriever” class from here.

Step 2. You need to create a jar file. You can build the project using maven 3 and create the jar file.

Step 3. Copy created  org.xacmlinfo.xacml.search.extension-1.0.0.jar in to <IS_HOME>/repository/components/lib directory

Step 4. Copy any dependency libraries for PIP module to <IS_HOME>/repository/components/lib directory.

Step 5. Open the entitlement.properties file which can be found at <IS_HOME>/repository/conf/security  directory  and register your new policy finder module. Following is the sample configuration and i have removed the default policy finder and have added new extended policy finder.

PDP.Policy.Finder.1=org.xacmlinfo.xacml.search.extension.SamplePolicyAttributeRetriever

Step 6. Restart the Server if already has been started.

You can actually debug this sample code by starting the WSO2 Identity Server in the debug mode as follows

wso2server.sh –debug 5005 (UNIX) or wso2server.bat –debug 5005 (Windows)

Then you can clearly see how the method in “SamplePolicyAttributeRetriever” are called by the PDP.

Multiple decision profile – Hierarchical resources

Posted on by Asela

In my previous post, we went though defining XACML policies for web application. Now i am going to try out the scenario, that is defined there with second approach. i.e. Multiple decision profile  with hierarchical resource profile.  Here i am using Identity Server which is an open source XACML engine that supports XACML 3.0, multiple decision profile and hierarchical resource profile

Step 1.  Web application (PEP) sends only the root resources and XACML engine (PDP) knows how to extract the child resources corresponding to root resources. Therefore XACML PDP must be fed with child resources. Identity Server provides an extension point for this. Therefore we can implement our own custom extension according to the our scenario. Please go through my previous blog on this.
Step 2.  You need to upload and publish these policies in to the XACML PDP as enabled policies. You can find more details from here.

Step 3. Create multiple decision request with scope attribute from PEP TryIt tool
Lets say.. web application needs to verify the permitted items in the index.jsp for user “asela” (“asela” is in privateUser role). Therefore web application needs to create a XACML request with scope attribute. Here TryIt UI does not support it. However we can create a draft XACML request from UI and need to add some more elements manually.

hr1

Followings are the important points on XACML request.

  • Root resource of the XACML request is identified by the attribute value with resource category; i.e “urn:oasis:names:tc:xacml:3.0:attribute-category:resource” and default resource id; i.e “urn:oasis:names:tc:xacml:1.0:resource:resource-id”.
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:root-resource-id" IncludeInResult="false">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">index.jsp</AttributeValue>
</Attribute>
  • Scope element of XACML request is identified by the the category “urn:oasis:names:tc:xacml:3.0:attribute-category:resource” and attribute id “urn:oasis:names:tc:xacml:2.0:resource:scope”.
<Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:resource:scope" IncludeInResult="false">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Children</AttributeValue>
</Attribute>
  • Scope value can be either “Children” or “Descendants”. Descendants means all the resources under the root resource. Children means level 1 Descendants. However this could be related with your resource finder implementation.
  • Here we are sending root resource name as different attribute (attribute id is different, it can be any id according to the policy. Here i have used “urn:oasis:names:tc:xacml:1.0:resource:root-resource-id”) as Polices have been written according to it and PDP wants it for evaluation.
  • “Include in result” important to distinguish the results of XACML response and It has been added in to the Root resource element. Then all child/descendant resources would contain in the XACML response

Finally XACML request can be found from here

Step 3. Use PEP TryIt  tool invoke the PDP (Or else you can invoke “getDecision” method of the PDP API using SOAP UI )

hr2

Step 4. You can see the multiple decisions within same XACML response and We can distinguish each decision using the attribute values that are returned.

md3

XACML response can be found here

Step 5. Web application needs to filter out the items (actions) that are permitted in the response and allow them to the user.

Multiple decision profile – Repeated attribute categories

Posted on by Asela

In my previous post, we went though defining XACML policies for web application. Now i am going to try out the scenario that is defined there with first approach. i.e. Multiple decision profile with repeated attribute categories. Here i am using  Identity Server which is an open source XACML engine that supports XACML 3.0 and multiple decision profile

Step 1.  You need to upload and publish these policies in to the XACML PDP as enabled policies. You can find more details from here.

Step 2. Create multiple decision request from PEP TryIt tool
Lets say.. web application needs to verify the permitted item in the index.jsp for user “asela” (“asela” is in privateUser role). Therefore web application needs to create a XACML request with all the items (actions) in the index.jsp page.

  • Multiple attribute values can be given as common separated way.
  • “Include in result” is important to distinguish the results of XACML response.

md1
Step 3. Use PEP TryIt tool invoke the PDP (Or else you can invoke “getDecision” method of the PDP API using SOAP UI )

You can find the XACML request from here

md2

Step 4. You can see the multiple decisions with same XACML response and We can distinguish each decision using the attribute value that is returned.

You can find the XACML response from here

md3

Step 5. Web application needs to filter out the items (actions) that are permitted in the response and allow them to the user.

XACML based Access Control for Web Applications

Posted on by Asela

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.

index.jsp
view-welcome  view-summary  view-status  modify-welcome  modify-summary

configure.jsp
view-apps   search-apps   add-app  delete-app  edit-app

download.jsp
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

You can find three XACML policies from here… Actually you can create these policies very easily using XACML policy editors. Please refer more details from here

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.

PIP for finding hierarchical resources

Posted on by Asela

If you are working with XACML.  You surely have heard about the PIP (Policy information Point). PIPs help to PDP by finding things that are needed for policy evaluation. PIPs are mostly extension points that can be implemented and plugged with PDP according to the your use case. Identity Server supports several PIP extension points. In my previous post,  I discussed on implementing PIP attribute finder. Today i am going to write PIP resource finder. PIP resource finder is an extension to feed the child resources in to the PDP for an given root resource. This is useful when we are using the hierarchical resource profile. Implementation PIP resource find is same as the PIP attribute finder. Therefore please go through my previous post for more details.  Child resources also can be retrieved from any sources such as JDBC, web services or any thing. In this sample i am not going to go through them much as we have already discussed on writing a PIP for JDBC.

There are two ways that you can write a PIP resource finder module

  • By implementing the “PIPResourceFinder” Interface. You can find the latest interface from here
  • By extending the “AbstractPIPAttributeFinder” abstract class You can find the latest abstract class from here

Step 1. Write a PIP module by extending “PIPResourceFinder”  Please find the “SampleWebAppResourceFinder” class from here.

Following are the methods,  you need to implement.

a).  init (Properties properties)   Here you can write the logic to initialize your module. Any properties that are defined in the entitlement.properties file,  can be access here.

As an example, JNDI name of the datasource  can be define as property value in entitlement.properties file. And is read here.  Also supported attributes are initialized inside this method.

b).  findChildResources(String parentResourceId, EvaluationCtx context)   Here you can write the logic to find your child resources for given parent resource. You can use XACML request, if you need some more information from it.

c).  findDescendantResources(String parentResourceId, EvaluationCtx context)   Here you can write the logic to find your descendant resources for given parent resource. You can use XACML request, if you need some more information from it.

d)   getModuleName()  name for the module

Also there are some method to implement for caching, we are not worry about them now.

Step 2. You need to create a jar file from your class. You can build the project using maven 3 and create the jar file.

Step 3. Copy created  org.xacmlinfo.xacml.pip.resource-1.0.0.jar in to <IS_HOME>/repository/components/lib directory

Step 4. Copy any dependency libraries for PIP module to <IS_HOME>/repository/components/lib directory.

Step 5. Open the entitlement.properties file which can be found at <IS_HOME>/repository/conf/security  directory  and register your PIP module. Here is my sample configuration and i have removed the default resource finder

PIP.ResourceFinders.Finder.1=org.xacmlinfo.xacml.pip.resource.SampleWebAppResourceFinder

Step 6. Restart the Server if already has been started.

Now You have successfully registered a PIP attribute finder with WSO2 Identity Server…!!!

Once you login in to the management console,  you can see that PIP resource finder has been registered successfully.  You can re-initialize it in run time.

r1

To test this resource finder,  you can use this policy and this request.  Please upload the policy in to the WSO2 Identity Server,  then  publish it to PDP and enable it.  You can then try out policy with TryIt PEP.

You can actually debug this sample code by starting the WSO2 Identity Server in the debug mode as follows

wso2server.sh –debug 5005 (UNIX) or wso2server.bat –debug 5005 (Windows)

Then you can clearly see how methods in “SampleWebAppResourceFinder” are called by the PDP.

Can XACML support to retrieve allowed permissions for given subject ?

Posted on by Asela

According to the XACML core specification, It only talks about a PDP that can provide authorization result of boolean values (Basically permit, deny, not applicable, indeterminate results and some additional data using advice and obligations). Basically from the PDP, application (PEP) can ask something like “is user authorized to do this” ?   And application (PEP) can not ask a question like “what are the allowed resources and actions for given user?”

However, with XACML 3.0,   application (PEP) can ask above question, if PDP supports for multiple decision profile. My previous blog post explains,  how we can use multiple decision profile to filter out resources that are only allowed for given user.  But here, application (PEP) must have knowledge about the static resources or actions that application have. I guess which is fine, As authorization policies have been created with related to the application. Then application must know what are the resources and actions (basically permissions) that contains within the application.

When we are going to introduce a XACML engine as an alternative for existing home grown authorization solutions, I have experienced that most of the users are asking…..
“is there any API to get allowed resources/actions for  user/role ? Our applications need this functionality”
“is there any way to do routine audits for users/roles? “
“we want to make a UI to show permissions that each user have. is there any way to achieve it? “
IMO,  Sometime these are valid… As an example, auditing  may be good requirement, where administrator wants to verify or monitor what resources that user can access at given time.

To achieve this, WSO2 Identity Server 4.5.0 provides some thing more than in the XACML specification, It provides some kind of search API  for  PDP policies. This search API has been exposed via web service API which is called as “EntitlementService” .   In this web service you can find a operation called  “getEntitledAttributes”. Following is the API details of this method.  Subject name (user name or role name) and subjectId (attribute id) are the required parameters.

    /**
     * Gets entitled resources for given user or role
     * This method can be only used, if all policies in PDP are defined with default categories i.e
     * subject, resource and action and default attribute Ids and #string data type.
     *
     * @param subjectName subject Name, User or Role name
     * @param subjectId attribute id of the subject, user or role
     * @param resourceName resource Name
     * @param action action name
     * @param enableChildSearch whether search is done for the child resources under the given  resource name
     * @return entitled resources as String array
     * @throws EntitlementException throws if invalid data is provided
     */
    public EntitledResultSetDTO getEntitledAttributes(String subjectName, String resourceName,
                                      String subjectId, String action, boolean enableChildSearch)
                                                                        throws EntitlementException {

Understanding Operation “getEntitledAttributes”

This method allows applications to check what are the resource that uses/roles can access, according to the XACML PDP in dynamic manner. As authorization mapping and authorization data (resources, actions, roles ) are stored in the XACML policies. Therefore internal implementation of “getEntitledAttributes” must know how to extract these authorization data and logic to provide the decisions. Internally it is happening by creating set of XACML requests and evaluating them (By use of multiple decision profile) and then extracting data in the requests that have been evaluated to “Permit“. Set of XACML requests are created using two sources. One is that the input parameters that it is send in to the “getEntitledAttributes” method and other one, Attribute values that are returned from the “getSearchAttributes” method that is defined in the “PolicyFinderModule” interface. Default implementation of this “getSearchAttributes” method is that it retrieves attributes values from the policy. But retrieving attribute values from the policy is not much straight forward in some case.  Therefore you have flexibility to extend it according to your requirement.  Basically,  with default implementation; “getEntitledAttributes” method  retrieve attribute values in the <AttributeValue> elements in the XACML policies and it works for the policies that does not have complex XACML functions.  Then some cases, you may need to implement “getSearchAttributes” method to support them.

Sample to Try out

Lets use some simple sample to see how it works.

Step 1. Upload a two sample policies and Promote them to PDP as enabled policies. You can find more detail on adding XACML policies in to PDP from this.

TestPolicy1.xml  ->  Role called “admin”  is permit for resource “foo1″ and action “bar1″.
TestPolicy2.xml  ->   User called “asela” is permit for resource “foo2″ and action “bar2″.

Actually  you can create sample XACML policy using simple policy editor. More details can be found here.

Step 2.  Go to PEP search option in Management console  and Let try to do following search. These searches are done by calling “getEntitledAttributes” operation in to “EntitlementService” API.

1. Let check allows resources/actions for role “admin”

50
2. Lets check allows resources/actions for user “admin”  who is already assigned to “admin” role

51

3. Lets check allows resources/actions for user “asela”

52

4. Lets assign user “asela” in to “admin” role and check allows resources/actions for user “asela”

53

XPath in XACML – Part 1

Posted on by Asela

XPath is playing an import role in XACML when policies are evaluated for XML based data. When XML data is passed across nodes, PEP can be an interception point that calls the PDP with passing XML data. Based on the XML data, PDP can take decisions.  Let see how we can develop simple policy that can be used to evaluate a XML data.

Lets take very simple use case.

  • There is medi.com health care application where online registered user (patient, doctors and so on) can examine patient data.
  • Patient data store returns any data that is requested for given patient id regardless of the login user to application.
  • Medi.com has authorization interceptor (PEP) between their web application and patient data store.  PEP would authorizes the requested data by calling to a PDP.
  • One authorization rule is “Users can only read his own patient data”

Lets build a policy for this

XACML Policy

Policy says “User can only read his own patient data”.  As an example,  you login to the medi.com web application with patient id “bob” then you can only read patient data that is store for “bob”

<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"  PolicyId="medi-xpath-test-policy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" Version="1.0">
<Description>XPath evaluation is done with respect to content elementand check for a matching value. Here content element has been bounded with custom namespace and prefix</Description>
<PolicyDefaults>
<XPathVersion>http://www.w3.org/TR/1999/REC-xpath-19991116</XPathVersion>
</PolicyDefaults>
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
<AttributeDesignator MustBePresent="false" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action" AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"></AttributeDesignator>
</Match>
</AllOf>
</AnyOf>
</Target>
<Rule RuleId="rule1" Effect="Permit">
<Description>Rule to match value in content element using XPath</Description>
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:any-of">
<Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal"></Function>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">
<AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"></AttributeDesignator>
</Apply>
<AttributeSelector MustBePresent="false" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" Path="//ak:record/ak:patient/ak:patientId/text()" DataType="http://www.w3.org/2001/XMLSchema#string"></AttributeSelector>
</Apply>
</Condition>
</Rule>
<Rule RuleId="rule2" Effect="Deny">
<Description>Deny rule</Description>
</Rule>
</Policy>

For try out this policy,  I am using WSO2 Identity Server which is open source XACML server. You can upload this policy in to the PAP of WSO2 Identity Server

xpath0

xpath1

XACML  Request

In the XACML request XML data is send to the PDP by the PEP interceptor.  XACML request contains the XML data under the content element

<Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" ReturnPolicyIdList="false" CombinedDecision="false">
<Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" >
<Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">bob</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
<Content>
<ak:record xmlns:ak="http://akpower.org">
<ak:patient>
<ak:patientId>bob</ak:patientId>
<ak:patientName>
<ak:first>Bob</ak:first>
<ak:last>Allan</ak:last>
</ak:patientName>
<ak:patientContact>
<ak:street>51 Main road</ak:street>
<ak:city>Gampaha</ak:city>
<ak:state>Western</ak:state>
<ak:zip>11730</ak:zip>
<ak:phone>94332189873</ak:phone>
<ak:email>[email protected]</ak:email>
</ak:patientContact>
<ak:patientDoB>1991-05-11</ak:patientDoB>
<ak:patientGender>male</ak:patientGender>
</ak:patient>
</ak:record>
</Content>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
<Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
</Attribute>
</Attributes>
</Request>

You can try out this request with the policy that is uploaded in to WSO2 Identity Server.

xpath2

xpath3

xpath4

XACML Response

PEP can get the decision based the result of the PDP

<Response>
<Result>
<Decision>Permit</Decision>
<Status>
<StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
</Status>
</Result>
</Response>

Lets build some complex scenario later…. 🙂