OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: XACML Delegation/Administration Requirements

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.


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