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