[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

*Subject*: **More complex delegation constraints**

*From*:**Erik Rissanen <mirty@sics.se>***To*: xacml@lists.oasis-open.org*Date*: Wed, 06 Apr 2005 19:03:38 +0200

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]