Authorization for Hierarchical Resources with XACML Multiple Decision Profile

Multiple decision profile is one of useful profile in XACML 3.0, when it comes to deal with most of authorization use cases. This profile can be modeled to define authorization for hierarchical resources by use of identifier called “scope” (based on Hierarchical Resource Profile). You can find more details from here. In this blog post, let go through an authorization use case for a set of hierarchical resources that have been stored in a repository.

Assume simple repository as following…


Access for these resources can be controlled based on user attributes or their roles.

Lets creates a use case as follows

1. There are three roles that users have been assigned. i.e. Manager, Employee, User

2. Users who are in Manager role can access all things under the root resource.

3. Users who are in Employee role can access all things under the root resource except business and leadership resources.

4. Users who are in User role can only access all things under the public resource.

Sample XACML 3.0  policy for this use case,  can be found here.

Here, with multiple decision and hierarchical resource profiles,  PEP (or application) does not want to ask authorization for each resources from the PDP.  It can ask authorization only for “root” resource.  Then response would contain the authorization decisions for all resources under the “root”  resource.

Balana has extension point called “ResourceFinderModule” where you can plug your own resource finders. These resource finders would help PDP to finding the child (or hierarchical) resources. In this sample, sample resource finder module has been implemented to cater the above requirement.

Also Attribute finder module is shipped with this sample. Actually this module must call to a user store and must retrieve the user attributes such as role data, But this sample attribute finder has been hard corded few names and corresponding roles as following

bob has assigned to User group
alice has assigned to Employee group
peter has assigned to Manager group

Please find the sample project here.  This sample,  would give you an idea how we can use resource finders to support multiple decision and hierarchical resource profiles. This could be extended according to your actual use case.

Discuss this article on Stack Overflow


  1. I would like to use the hierarchical example but I have huge resource tree. I would like to say all resources under a subtree are allowed access a particular group. Doing the above method is not feasible as the policies tend to be too verbose and too many Condition/Apply/Attribute statement are required when my resource tree is huge.

    I would like to have use regular expression kind of capability for this kind of request but I couldn’t come with a policy that takes regexp match in condition.

    In my case all tables under schema and all columns inside a table needs access.

    Please suggest how to go about doing this..

  2. How do I go about doing when the resource tree is huge and I have N depth tree. I would like to say all resources under this subtree are allowed access to a group/role. I couldn’t use the regexp in conditions . Please suggest – thanks Rajesh @Neustar

    1. Normally in a large tree, We can consider, there can be more than on root node… Therefore we can write more than one policy for each node… As an example, here i have written the policy considering root as “root” but we can consider, “public” and “private” as also root nodes. So you can write a policy thinking that “public” is the root and then “public”… Therefore we do not want to add all in to one policy with top root element. Else, you can use regexp match function to define element.

      <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">
                        <AttributeValue DataType="">(read|write|delete).*</AttributeValue>
                        <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action" DataType="" MustBePresent="true"/>
      1. I tried writing two policies as per you suggestion but instead of having action-id filtering in the Targets Match criteria, I have specified a resource.



        First it was not finding any applicable policies in policy match as my PIP was returning child resources of LSMSADM. Once I added the parent resource to PIP, in the above case LSMSADM, policy could be found. Shouldn’t the PDP first find the policies based on request context rather than what PIP returns.

        Thanks a lot for your response.

Leave a Reply

Your email address will not be published. Required fields are marked *