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: FW: [xacml] XACML Delegation/Administration Requirements


I have an additional requirement which actually falls under the points below, but I think we need to provide a specific mchanism to make it easier and less arror prone to express.

below I said:

>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 question is, how easy is it to "create policies which enable a. and/or b."

Consider the common usecase: Mary is the manager and approves expense reports for her dept. When she is on vacation, Jack can approve expense reports.

I think we need a convient way to say "Jack is allowed to do such and such, but only if Mary is allowed to do it" Mary might or might not be issuer of this policy. As I understand the current proposals, there is no way to do this except by duplicating the rules that apply to Mary.

I am not sure what the right syntax is. This seems like a condition, but there might be reasons to make it more visible in the policy, for example as a new Effect value.

Also I am not sure how general this needs to be. For example, in the example, Mary and Jack are Access Subjects. Should it work for other Subject types? Other kinds of inputs?

Hal

-----Original Message-----
From: Hal Lockhart 
Sent: Wednesday, January 05, 2005 11:42 AM
To: xacml@lists.oasis-open.org
Subject: [xacml] 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.

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.



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