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

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

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

May be i am getting you wrong, in the above mentioned policies, Role A dont 
have access to op1( ) , but still we have to check for delegation policies 
thats why i am saying that "Still there is some result 'left'  (in the form 
of delegation policies) to authorize ".



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

oh, now i got your point, that you are considering the RBAC profile for both 
Administration policies and for non-Administration policies (Issued by 
User). But what about then putting a condition inside PPS of Role A, whose 
result can be deny ?. I am not consierding this case, currently i am 
focusing on the use of RBAC profile for Administraton policies only. I mean, 
since every Role can issue a policy regardless of role heirarchy, so i 
dontunder stand why we need to use these PPS here. PPS simply meant to 
abstract role heirachies , but we dont need role heiraches, since every role 
can issue a policy, which has to authorized against administration policy . 
Agreed ?


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


Here, i am concerend about one thing. Table in Section 5.2.5 says that it is 
necessary to match all the elements in the target. Now, Do you think so, 
that Delegate_RPS_4_Role_B will match with a request, since empty Subject, 
Resource, Action are used and in the  Delegate_PPS_4_Role_B empty Delegate 
is used.


regards
Muhammad.