Pushpalanka's Blog

This is 6th post of a series of posts, after this post on writing XACML policies having multiple rules, http://pushpalankajaya.blogspot.com/2013/06/xacml-30-policies-multiple-rules-5.html . Here we will look into the following requirement which is more likely in practice. The operation getVesrion1 and getVersion2 in the service http://localhost:8280/services/Customers should be accessed by any user Request to any other service or operation should only be accessed by the users belong to the group(s) admin_emps or admin or both Here the policy written to meet this authorization requirement, <Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"  PolicyId="testOr" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" Version="1.0">    <Description>Test Or</Description>    <Target></Target>    <Rule Effect="Permit" RuleId="primary-group-emps-rule...

This is the 5th post of a series of posts after the post XACML 3.0 policies - Restricting conditions - OR http://pushpalankajaya.blogspot.com/2013/06/xacml-30-policies-restricting-condition.html. Here we will look at a more practical scenario, which uses a combination of rules to satisfy the requirement which is defined as follows. The operation getEmployees in the service http://localhost:8280/services/Customers should only be accessed by the users belong to the group(s) admin_emps or admin or both Request to any other service or operation should fail But the users admin1 and admin2 should be able to access any resource irrespective of their role <Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"  PolicyId="testOr" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" Version="1.0">    <Description>Test Or</Description>    <Target></Target>    <Rule Eff...

This is a follow up post of the previous post on "XACML 3.0 policies - Restricting Conditions" http://pushpalankajaya.blogspot.com/2013/06/xacml-30-policies-restricting.html. There we saw how to force a user to satisfy some distinct values for a given category. Here we will see how to force to satisfy at least one of the given distinct values for a given category. The requirement is defined as follows. The operation getEmployees in the service http://localhost:8280/services/Customers should only be accessed by the users who belongs to at least one of the group(s) of admin_emps and admin. Request to any other service or operation should fail Here is the policy wrote to satisfy this requirement, <Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"  PolicyId="5" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" Version="1.0">    <Description>Test Or</Description...

This is the third post of a series of post, after writing XACML 3.0 policies( Writing XACML 3.0 policies, Diverse Rules Per Operation - 2 ) to satisfy several rules for different operations. With this I am to share a policy written with a much restricted condition for the rule. Following is our requirement in points. The operation getEmployees in the service http://localhost:8280/services/Customers should only be accessed by the users belong to both the groups admin_emps and admin If the user belongs to more groups than admin_emps and admin - request should fail Request to any other service or operation should fail In other words the operation should only be accessed by users belonging to both the groups admin and admin_emps, no more, no less. Here is the policy written for this requirement. <Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"  PolicyId="testAnd" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorith...

This is a continuation from my previous post ' Working with XACML 3.0 policies for fine-grained authorization -1 '. Here I will share a sample XACML 3 policy which defines two distinct rules to act over two distinct resources, followed by few sample requests to understand it's behaviour. Let's imagine a requirement like as follows. The operation getCustomers in the service "http://localhost:8280/services/Customers" should only be accessed by users belonging to the admin_customers group. The operation getEmployees in the service "http://localhost:8280/services/Customers" should only be accessed by users belonging to the admin_emps group. Requests to any other service or operation should fail. I have wrote following policy to satisfy this. It's bit longer than the previous policy, but same pattern applies. <Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"  PolicyId="sample" RuleCombiningAlgId=...

With this post I am to share few things I learnt on XACML 3.0. This will be helpful to you if you are newly learning XACML or already familiar with XACML 2.0 and trying to upgrade to XACML 3.0. Going through the XACML 3.0 OASIS specification and trying out few sample polices and requests observing the responses was the best way to learn this I have experienced. So I will share the samples I tried out. You can try out the same with WSO2 Identity Server which supports XACML 3.0 specification with Balana open course engine . My previous blog post, Try out XACML policies with WSO2 Identity Server will help you to get start with it. This will be the first post of a series of posts and will carry the corresponding XACML 3.0 policies for the sample XACML 2.0 policies mentioned in the blog at references. Let's go directly to a sample. Imagine a requirement where we want to provide fine-grained authorized access to the service "http://localhost:8280/services/echo/" lett...