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

[Erik Rissanen <mirty@sics.se>]

Muhammad Masoom Alam wrote:

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


If you do not have an access result that says "permit", then you do not
need to generate an administrative request. Perhaps you mean that, even
if you get a not applicable for the access request against one policy,
you still need to try all other policies. Yes, that is true, but all the
administrative policies will evaluate to not applicable to an access
request.

>
>
>> 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, that is what I thought what you wanted to do. :-) Anyway, if you
want to use the RBAC profile for only administrative policies, you can
do so. Just use some other form for the access policies. They are
independent.

With regard to your comment on that there is no need for role
hierarchies since every role can issue policies. This does not need to
be the case. You could have a role called "administrator" that can issue
policies, and a role "user" which cannot, for instance. You could also
have a role hierarchy among the administrative roles if you want to.

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


If you read the XACML spec, then section 5.5 says that if an element is
missing in the target, then it matches all requests. It's the same in
the delegation profile, with the exception that a target without a
Delegate element does not match a request with one, and vice versa.

/Erik