Re: [xacml] XACML Delegation/Administration Requirements

[Erik Rissanen <mirty@sics.se>]

This is exactly in line with what we here at SICS have been working on,
though our work has been on administrative delegation, not on dynamic
delegation.

I have an implementation of what I have done, and it works, but is not
100% complete with regards to all features of XACML. It's based on the
sun xacml code. I didn't need to modify the XACML 1.1 specification in
any way, but rather used the public extension points. There is a new
policy combination algorithm, a new function, etc.

I have been planning to write a document with all the details, but I've
been busy for a couple of weeks, so I haven't done it yet. I expect to
have it done withing a week or two.

Briefly, what I have done is in line with the policy paper we wrote on
the subject for a recent W3C workshop:
http://www.w3.org/2004/08/ws-cc/erbsf-20040902

For delegation in XACML we differentiate between administrative policies
in contrast to access policies, and we also differentiate between
trusted root policies and delegated policies.

Access policies have a condition element in the rules that require a
specific environment attribute to be present in the access request. That
attribute marks the request to be an access level request.
Administrative policies instead have a condition on an delegation chain
attribute in the request. The delegation chain attribute is used to
express that the request is asking whether an access permission was
allowed to be delegated in the manner defined by the delegation chain
contents. There is a new data type to express a constraint on who may
delegate to whom. The condition uses a new function to compare this
constraint to the chain.

(If a rule has neither an access level or delegation condition in it, it
will authorize both access level requests and all possible delegation
chains.)

A delegated policy contains an obligation to authorize the issuer of
that policy. That means a new request is made looking for an
administrative rule that would permit the delegation of a permission to
allow the original access request. This new request is formed by
creating a delegation chain with the issuer contained in the obligation.
The process may repeat itself in case an administrative delegation was
delegated. It ends when a request matches a trusted root policy which
will not contain any obligation for a new request.

The source of policies must be authenticated and the obligation to
authorize the issuer must be added by a trusted component when the
policy is read into the policy repository. How this is done is outside
the scope of XACML. I use the XACML/SAML profile for digitally signing
policies.

To prevent unauthorized root policies I use operating system level
access control in combination with armed guards. :-)

I have not found any way to "flatten" chains ahead of access time. I
think Frank has an idea for how to do it, but I was not able to figure
it out.

I will try to have this written down properly as soon as possible and
make the code available for all to try.

I will meet you this afternoon at the the teleconference.

Erik


On Wed, 2005-01-05 at 11:41 -0500, Hal Lockhart wrote:
> I was explaining to someone internally what we were trying to accomplish with the D/A proposals and I ended up writing the following. I thought I would post it to the list to see if there is general agreement on what we are trying to do.
> 
> Basically the proposals are intended to solve two related usecases, which I believe are actually the same problem.
> 
> 1. Policy Administration - Control the types of policies different individuals can create and modify policies. Typically different individuals would be allowed to create policies about certain sets of Resources. Alternatively administration might be divided up by Action type, Subject or some other properties.
> 
> In XACML 2.0 the question of under what circumstances policies can be created that will utilized by a given PDP is out of scope of XACML. The spec essentially says that some policies exist which the PDP will use. 
> 
> It is also desirable to support multiple levels of indirection, so it should be possible to say things like "Jack can create policies that let Mary create policies about the Financial Servers."
> 
> 2. Dynamic Delegation - Permit some users to create policies of limited duration to delegate certain capsbilities to others. XACML 2.0 allows policies that say "Mary can do something on behalf of Jack" by means of different Subject Categories. But, it would be useful to allow people to generate policies on the fly that say "while I am on vacation, Mary can approve requests." This requires the ability to create policies which control the policies that can be created.
> 
> However in meeting these two usecases, it is NOT desirable to require either of the following to always be true:
> 
> a. Anything you can do, you can delegate to someone else to do.
> 
> b. If you can delegate something, you can always do it yourself by generating the necessary policy which applies to you.
> 
> It should be possible to create policies which enable a. and/or b., but they should not be "wired in."
> 
> The main difference between usecases #1 and #2 is how policies get accessed. In #1, most likely policies will be found in some repository or set of repositories. There will be some simple enforcement mechanism which says that the "Issuer" field in the policy must correspond to the person who created or modified this policy. In #2, policies might need to be carried in application requests or accessed dynamically via some back channel. In this case, signatures or some other such mechanism would be used to verify the Issuer's identity. 
> 
> Note that in both cases having a policy from Fred, signed by Fred does not mean the policy will be enforced. It merely means it will be considered as a candidate. It is still necessary to find a chain of policies back to the root (PDP) in order for Fred's policy to be enforced.
> 
> It is also desirable to arrange that policy evaluation can be optimized by doing as much work prior to access request time as posssible. It should be possible to "flatten" policy chains to an equivalent form using whatever policies are in hand.
> 
> Hal
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.