Re: [xacml-dev] Some queries regarding RBAC and XACML Profile fordelegation.

[Erik Rissanen <mirty@sics.se>]

Muhammad Masoom Alam wrote:

> Hi Erik,
>
>> If there is no match, then there is no result to authorize. Why would
>> check for a delegation policy in that case?
>> If there is a deny, yes, I can see that you might want to check for a
>> delegation policy, but the current draft does not cover that case yet.
>> It is till work in progress, so I don't have an answer right now.
>
>
> if there is no match, still there are some results to authorize. suppose
>  " Role A dont have any access to an operation op1( ) but it is
> delegated under certain conditions by Role B and Role A have access to
> op2( ) and also Role C is the super role of Role B".
>
> How i am percieving this :
>            RPS for Role A using XACML Profile for RBAC.
> <policyset>
>      <Target>
>         Role Definition for Role A
>      </Target>
>    <PolicySetIdReference> PPS_RoleA </PolicySetIdReference>
> </policySet>
>
>    PPS for Role A
>
>
> <policyset>
>  <Rule Id="1">
>   <Target>
>         Permission Definition that Role A can access op2( )
>   </Target>
> </Rule>
> </policySet>
>
> Note: Putting, permisison in the rules target, gives an additional
> flexibility of putting more permissions in a single permission policy
> set, otherwise standard way can also be used.
>
> now if a request comes from Role A for op1( ), then, RPS will match,
> but PPS will not match, so it is not applicable (this is my findings).


yes, this is true. And this means there is no result to authorize, so
there is no reason to do the delegation processing in this case.

What I think you want is that a member of role B delegates the right to
op1 to the role A. In that case there would be something like this:

           RPS for Role A using XACML Profile for RBAC.
<policyset>
     <PolicyIssuer>Someone who is a member of role B</Issuer>
     <Target>
        <subject>Role Definition for Role A</subject>
     </Target>
   <PolicySetIdReference> PPS_RoleA_2 </PolicySetIdReference>
</policySet>

   PPS for Role A

<policyset Id="PPS_RoleA_2">
 <Rule Id="1">
  <Target>
        any subject
        op1( )
  </Target>
</Rule>
</policySet>

This way an access request be a member of role A would match this and
allow access to op1. That permit has then to be authorized. The
administrative policies in my example below would allow it.

>> Adding administrative rights to roles is done the same way as adding any
>> other right. Just set the role attribute as the subject of the target
>> and the delegate a part of the target as well. In the case of the RBAC
>> profile, just set the Delegate of the RPS to empty and then set the
>> Delegate element in the PPS to whatever right you want to give.
>>
>> The only problem is that currently a single RPS cannot match both access
>> policies and administrative policies, so you need to keep them separete.
>> The access RPS has no delegate element, and the delegation RPS has an
>> empty delegate element.
>
>
> Now as Role B have delegated the rights to Role A for op1( ), there
> fore, we have to check the delegation policies:
>
>            Delegate_RPS_4_Role_B
>
> <policyset>
>      <Target>
>         <AnySubject/><AnyResource/><AnyAction/> {I mean  empty }
>     <Delegate>
>               Role B
>     </Delegate>
>      </Target>
>    <PolicySetIdReference> Delegate_PPS_4_Role_B </PolicySetIdReference>
> </policySet>
>
>
>                  Delegate_PPS_4_Role_B
>
> <policyset>
>
>
>
>
> <Rule id="1">
>      <Target>
>         Permission Definition that Role A can access op1( )
>
>     <Delegate>
>            <AnyDelegate/>
>     </Delegate>
>      </Target>
>  <Condition>
>     under which condition Role A can access op1 ( )
> </Condition>
> </Rule>
>
> <Rule id="2">
> ....
> </Rule>
>
> ...
>
> </policySet>
>
>
> This approach has the flexibility that as Role C is the superRole of
> Role B, it can also reference the PPS of Role B. If i put empty
> delegate in RPS and a delegate with Role B in PPS, then you can simply
> see that it will not work if it is referneced by the Role C.
>
>  The bottom line is that:" if Role B can delegate a situation (Role A
> --> op 1( ) ), his super role Role C can also delegate the same
> situation under the same conditions"


Yes, you are right. The above is exactly what I meant, but I made a
mistake when I was trying to explain it. For some reason, I mixed up the
subject and the delegate of the RPS in my explanation. :-( The above
example is correct, though you probably don't want the references to
role A in the situation:


           Delegate_RPS_4_Role_B

<policyset>
     <Target>
        <AnySubject/><AnyResource/><AnyAction/>
    <Delegate>
              Role B
    </Delegate>
     </Target>
   <PolicySetIdReference> Delegate_PPS_4_Role_B </PolicySetIdReference>
</policySet>


                 Delegate_PPS_4_Role_B

<policyset>
<Rule id="1">
     <Target>
       any subject
        op1( )
    <Delegate>
           <AnyDelegate/>
    </Delegate>
     </Target>
</Rule>
</policySet>

The above means that members of role B can create access rights to op1.
It would authorize the access for role A given by the access policies above.

Hope this helps.

/Erik