[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-dev] Some queries regarding RBAC and XACML Profile for delegation.
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]