Pushpalanka's Blog

Custom deployers is a concept introduced to Axis2 to increase it's flexibility and enhance the dynamic nature. With this article on Axis2 Custom Deployers, it's originator himself explains it's background and procedure in details. With this post, I'll just share the steps I followed in using this feature. Following is the basic structure of a custom deployer. There needs to be a class that has implemented 'org.apache.axis2.deployment.Deployer' interface and a component.xml file that carries some required properties for the deployer. Following is the basic structure of a CustomDeployer class. public class CustomDeployer extends AbstractDeployer {     private static Log log = LogFactory.getLog(CustomDeployer.class);     private File userMgtConfigFile;     private RealmConfigXMLProcessor realmConfigXMLProcessor = new RealmConfigXMLProcessor();     public void init(ConfigurationContext configurationContext) {  ...

The commands I came across with, while working with svn in Linux. Find and remove all the .svn folders inside a folder - This is useful when we have checkout the code from a svn repo and want to remove it from version control. find . -name .svn | xargs rm -rf Add a new folder to version control - When we have a folder that is already under version control and want to add a new one inside it. svn add Commit the made changes svn ci -m "a useful message about the commit" Remove some specific folders like target and IDE specific data from version control, but keep the data in our local machine. svn delete --keep-local <file name>  Check out a particular revision of from SVN when we know the revision number  svn co -r <revision no.> <path for the checking out folder or file> Save the difference of code to a file svn diff > <filepath>

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

WSO2 Identity Server (IS) is rich with entitlement management based functionalities which are implemented adhering to the standards. It provides fine-grained policy based access control via XACML supporting both XACML 2.0 and XACML 3.0 specifications. Going one step further it provides a friendly user interface to define complex XACML policies in a simple way, with a Tryit tool to see the policy impact. This is a great tool not only to see whether the policy behaves exactly as we expected, but also to learn XACML as a newbie. The UI explains itself how it needs to be used and we can just learn playing with it. This is just a note if someone just need to get away with it at once. Once we start WSO2 IS and go to management console at http://localhost:9443/carbon, the default URL and give credentials user name:'admin' and password: 'admin' we are ready to go. In Main menu, hit circle 1 and we will be in a page as above. Here we see options to define policies, ...