Re: [xacml] On delegation constraints

[Erik Rissanen <mirty@sics.se>]

Frank,

Yes, this is exactly what I mean!

The use cases I presented are covered if we introduce this "second level
of administrators". Also note that I suggest that this second level
could be "repeated", in the sense that delegation could go on for an
arbitrary number of steps, as long as all administrators in the chain
satisfy the constraints of the second level. What I mean is that the
fact that there are two levels of constraints, does not mean that a
chain of delegation has to be exactly two levels deep. Rather that it
must start with an administrator which satisfies the first constraint
and the remainder of the chain must satisfy the second constraint.

My implementation allows arbitrary levels of constraints, but I doubt
there is need for too many levels in practice. I can imagine use cases
for a third level as well, but I am not sure how realistic those are.

For an example of a three level constraint, we could imagine that an
organisation outsources management to another organisation, which can
then delegate it back to the original organisation is some cases. Maybe
this is a bit superficial?

In any case, I think the second level of constraint will be very useful.
It may also be the case that a general model that allows (but does not
require) the use of an arbitrary number of levels would not hurt, and
may be useful in situations that we cannot think of ourselves.

Best regards, Erik




Frank Siebenlist wrote:

> Hi Erik,
>
> Just to clarify, currently, the xacml-3 doc proposes that we can express:
>
> "The policy-issuer states that only certain administraters are allowed
> to manage the access control policy for certain subjects to invoke
> certain actions on certain resources."
>
> In this way the issuer can restrict the "administrators" to be a
> member of a certain group and such.
>
> Adding one more level of administrators would yield something like:
>
> "The policy-issuer states that only certain administraters are allowed
> delegate the administrative rights to certain other administrators to
> manage the access control policy for certain subject to invoke certain
> actions on certain resources."
>
> Is this the extra level you're asking for?
>
> Regards, Frank.
>
>
>
> Erik Rissanen wrote:
>
>> Hello everybody,
>>
>> In the current delegation draft (draft 1) there is a formulation in
>> section 3 (on line 93) that defining a constraint for the subject of a
>> delegated delegation right "seems too complex to be workable". I don't
>> think this is the case and my experimental implementation has this
>> feature. During the focus group meeting last week I raised a question
>> about this and during the brief discussion there was a question about
>> what the use cases for such a feature would be.
>>
>> I can see use cases in the application I am involved in. There is a
>> desire to limit administrative rights to only certain people. In our
>> case it could be to limit the administrative rights to people within a
>> headquarters or to only people who have certain training.
>>
>> I can also imagine (though I don't have real knowledge on this
>> personally) situations in a commercial setting where there is a legal
>> liability to perform administration in a particular way. For instance at
>> a hospital, it could be the case that only certain certified people
>> should be able to administer rights in order to reduce the risk of
>> errors. Under such ligal liability to follow certain procedures, it
>> would be useful to be able to specify the policy in the administrative
>> rights in XACML, and not to rely on human communication only.
>>
>> It is of course the case, as Frank pointed out in the discussion about
>> restricting delegation depth, that prevention of delegation cannot be
>> enforced in the strict sense. If I have a right to do X, a computer will
>> not be able to enforce a ban to grant X to someone else, since I can
>> simply do it myself on behalf of the other person. (The SPKI
>> specification, among others, discuss this.) However, I still believe
>> that specifying such a policy has value, in the sense that it
>> communicates to people what the policy is and keeps the rights cleaner
>> by preventing the explicit creation of undesirable rights.
>>
>> For those who have studied my implementation in detail, I can say that
>> the model in it is more general than I have use cases for. The
>> implemented model permits the specification of constraints of arbitrary
>> depth, which likely is not very useful in practice. In our application
>> we use constraints of depth one only, which cover the use cases above.
>>
>> I would suggest that the model for administrative rights for the
>> upcoming XACML would include at least one level of constraint on the
>> possible subjects of delegation rights. In case of long chains, all the
>> issuers in the whole chain would have to meet the constraints. In my
>> implementation this is equivalent to a constraint of length one with the
>> "MaySkipOrRepeat" attribute set to true.
>>
>> Best regards, Erik
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail. You may a link to this group and all your TCs in
>> OASIS
>> at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>