More complex delegation constraints

[Erik Rissanen <mirty@sics.se>]

Everyone,

During the meeting last week I promised to explain more about how we at
SICS express delegation constraints at "multiple levels" for a
delegation chain.

The full paper is available at
http://www.sics.se/isl/pbr/papers/ConstraintDelegation.ps

I will try to briefly outline the idea here, contrast it to the other
proposals, and discuss whether there are any use cases for it.

A chain of delegation is simply a list of people who have delegated a
right to each others until finally an access right was created and an
request if performed. In this email I represent people with letters, so
a chain could be like:

abcx

Which would mean that "a" created an administrative right for "b", who
created an administrative right for "c", who created an access right for
the access "x" (or "situation" by the draft proposal terminology).
Basically each of these letters is a context Subject element, except the
last one which also contains the resource and action.

We use a language similar to regular expressions to define constraints
on what a chain a delegation may look like. I represent constraints with
capital letter, so:

ABCX

would be the contants of an administrative right. Each letter represents
a constraint on the administrative subject, except the last one which is
a constraint on the access subject. Basically, each constraint is a
policy Subject element, except the last one which is an access
permission Target and Condition.

The contents of a right, any right, in our model is simply a constraint
like that. The first constraint in the constraint list defines the
subject(s) of the right. In the case of "ABCX", it is an administrative
right which grants anyone who meets "A" to define a right that is a
subset of "BCX".

To take something simpler, "AX", is an administrative right to create an
access permission which grants any situation that satisfies "X". Suppose
person "a" issues a right Y:

a: Y

and suppose that "AX" is a root policy. We have the following two rights:

root: AX
a: Y

Now suppose that access "z" is attempted, where z contains a subject,
resource and action with associated attributes. If z matches Y, then we
would get a "permit" under the condition that "a" is authorized to allow
the situation z. We have a repeated request for an administrative
permission: "az". If a meets A and z meets X, then the request "az"
would match the right "root: AX", and the request is permitted.

I hope this makes sense to you all. :-)

Multiple levels mean longer chains and longer constraints. We could have
the following rights:

root: ABCX
a: BCX
b: CX
c: X

In this case there is an access request x. It matches the last right,
which causes a request cx, which in turn causes a request bcx which
finally causes a request abcx, assuming that all constraints match.

We also allow for a kleene star in the constraints, so we could write a
constraint like this:

root: AB*X

which would mean that the right may be delegated any number of times
within the constraint B. So the chain abcdx would be permitted in case
b, c and d would meet B and a would meet A.

In our model, we can specify the exact length of permitted delegation
chains by defining a constraint without a star. For instance any chain
supported by "ABCX" would have three administrators and the final access
request.

As I explained above, we can express the right to delegate an unlimited
number of times with the star construct, but we do not have any way to
express "at most x times" in our model, since we have not needed it.
However it would be simple to add it to the model.

Personally, I think this model supports more expressive power than is
really needed. So far, in designing our application, we have found use
only for three forms of rights:

X
AX
AB*X

The first one is a regular access permission. The second one is the
right to create an access right. The third one is the right to create an
access right X, or to create and administrative right for B, with the
limitation that all further delegation must stay within B.

The current proposal (draft 01) supports the two first ones, but lacks
the third one, which I believe is a usefull case. There is a desire to
limit the depth of delegation, so we could also include the case:

AB(n)X

where n indicates a maximum depth. As a special case B could be a
constraint which permits all subjects, in which case there is no limit
on to whom an administrative right may be delegated.

We have also thought about whether the form

AB*C*X

would be usefull. One could imagine an outsourcing scenario in which
case organization O grants the right to manage rights within O to
another organization P, but I am not certain about how realistic this is.

The general constraint model is not difficult to implement, so one could
argue that it would be a good idea to implement it, and let users decide
themselves how many levels of constraints they need. At a minimum the
cases "X", "AX", "AB*X" and "AB(n)X" should be supported.

The sample implementation I have made implements the most general model.

Best regards, Erik