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

["Muhammad Masoom Alam" <Muhammad.alam@uibk.ac.at>]

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

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


best regards,
Muhammad.