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

[Erik Rissanen <mirty@sics.se>]

Muhammad Masoom Alam wrote:

> Hi Erik,
>
>>> The first question is, whether an Issuer can Constrain the delegation,
>>> or Delegation can only be constrained by Adminisration Policies. As
>>> stated in Profile that "In case <PolicyIssuer> element is present,
>>> then combinining Algorithms that can result in "Deny" SHALL NOT be
>>> used". ??
>>
>>
>>
>> I don't understand this question. Sorry. :-(
>
>
>
> When a user asserts about some situation (e.g. Mallory asserts that
> alice can use the printer), can he also constrain the situation i.e.
> can he put some conditions too in a policy ??
> If he can put some conditions then, result can be deny as well, which
> this profile simply dont allow. Profile states that "In case
> <PolicyIssuer> element is present,
> then combinining Algorithms that can result in "Deny" SHALL NOT be
> used". ??


We have not worked out how deny results will work yet, so I cannot
answer this. I am sorry if the profile in its current draft is a bit
confusing. What we really mean for now is that you should use a
permit-overrides algorithm and that the delegation processing model will
treat a "deny" the same as "not applicable".

Oh, btw, an another condition would make the result "deny", but "not
applicable".

> The point is that i am not going at all for ARBAC at all e.g.
> user-role assignment, permission-role assignment and role-role
> assignment.
> I want that the Actors (e.g. Carol which in my case is represented by
> role Manager) which can delegate can be represented by roles in order
> to aggregate their rights based on their roles
> If i am able to represent these usres/Actors by their roles, it will
> easier for me to manage them rather than specifying delegation
> policies for single users which is not at all handy in distributed
> envoirnment.


This is no problem. The examples in the profile are just examples. The
Delegate in the target does not have to refer to a single individual.
You can put an role attribute there instead.

>> I don't understand your example (quoted below). The first policy set has
>> an unbalanced Policy element, and I am not sure how you intended it to
>> be. According to the RBAC profile there is no Policy element in the RPS,
>> so I assume that the target is really for the PolicySet. But in that
>> case, your policies will not match any request, since the top level
>> target has a delegate element and the nested policy set's target does
>> not have it.
>
>
>
> The thing is that how we can combine these two policy sets i.e. RPS
> and PPS. can i use an 'dont-care' Delegate element in the PPS so that
> it shall match just to implement role hierarchy.


Oh, I see now what you want. You want to add administrative rights for
roles. There is no way right now in the profile to define a target that
will match both access and administrative requests, so you cannot mix
access rights and administarive rights in the same role using only a
single policy set. For now, I suggest you create a second RPS for
administrative rights, which can then refer to another PPS with the
administrative rights.

For this second RPS, you can use a empty Delegate element in the target,
which will match any administrative request and then you can fill in the
details in the PPS.

I will add this issue to the open issues list.

/Erik