Re: FW: [xacml] XACML Delegation/Administration Requirements

[Erik Rissanen <mirty@sics.se>]

Hal Lockhart wrote:

>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."
>  
>
I think that a, in the literal sense above, is probably undesirable. In 
general it is possible that different resources have different owners, 
so there may not be a single authority who should have the authority to 
grant the right for someone to delegate _all_ that they can do. However 
I can see that it could be useful to express in a particular policy or 
rule that it can also be delegated to someone else. This is something my 
experimental delegation cannot support without duplication of rules, as 
you say.

With regard to b, in my proposal, if a user has a right to delegate 
something, she can issue a policy that would grant her the access right, 
if that is in the scope of her right to delegate, so b is not a problem. 
We can express both that she should be able to delegate to herself, and 
that she should not be able to delegate to herself. (However, again, 
this would mean duplication of rules.)

>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?
>  
>

In principle, this could be expressed with an obligation: The request 
for Jack to access would result in an obligation to run the same access 
request with Mary as the subject instead of Jack. The difficulty is in 
verifying that such delegation was authorized, since not any access 
permission should be delegatable to anyone by anyone.

There are three separate (but related) authorizations in the use case:

* The access rights of Mary.
* The delegation rights of Mary.
* The access rights of Jack.

We could define the last one as a rule which matches all resources and 
actions in a policy with the special obligation. The problem is to how 
to define the middle one without duplicating much of the first one. Note 
that it is possible that the resource owner might not want Mary to 
delegate her rights to the resource, in which case she may not have 
delegation rights for everything she has access rights for.

A difference between the access rights and the delegation rights is that 
the delegation rights will contain a different subject from the access 
right. This is since it does not apply to Mary at the access level, but 
contains a constraint for to whom Mary may delegate. I think such a 
constraint is a good feature in a general mechanism, even though in some 
cases there may not be any limitations for whom you can delegate to.

I think we could support all cases if we modify my proposal by using a 
different subject category for delegation constraints. In that case we 
can combine delegation and access rights in the same rules, by using the 
different subject categories.

I can imagine something like this:

Combined access and delegation rights for Mary:

<Target>
  <Subjects>
    <SubjectMatch Category="access-subject">Mary</Subject>
    <SubjectMatch Category="delegation-constraint">Something that 
matches Jack</Subject>
  </Subjects>
  <Resource>...</Resource>
  <Action>...</Action>
</Target>
<Condition>Delegation chain is "Mary"</Condition>

When mary delegates she issues the following policy to grant to Jack 
everything she has the delegation right for:

<Target>
  <Subjects>
    <SubjectMatch Category="access-subject">Jack</Subject>
  </Subjects>
  <Resource><AnyResource/></Resource>
  <Action><AnyAction/></Action>
</Target>
<Obligation id="Authorize-issuer">Mary</Obligation>

The access request of Jack would look like this:

<Request>
  <Subject category="access-subject">Jack<Subject>
  <Resource>...</Resource>
  <Action>...</Action>
</Request>

It would match the second rule/policy. The obligation would be converted 
to a new request with the following subject:

<Request>
  <Subject category="delegation-subject">Jack<Subject>
  <Resource>...</Resource>
  <Action>...</Action>
  <Environment><DelegationChain>Mary</DelegationChain></Environment>
</Request>

Note that this uses a different subject category, which my current 
proposal does not. This second request will prevent Mary from delegating 
more than she has right to delegate. It would match the first policy, 
thus granting Jack access. If there is no delegation right for Mary to 
grant this access, the request would be denied.

A neat feature of this approach would be that there is no need for the 
condition for an empty delegation chain in access permissions any more 
since a request for an administrative permission could not match an 
access right since the subject categories would be different. This would 
provide for better compatibility with non-delegated XACML.

With this there is still the possibility that she will grant Jack rights 
she does not possess herself. This could happen in case she has rights 
to delegate permissions she cannot exercise herself. If we want to 
prevent this, we could define a new kind of obligation, that would cause 
a request which would check that Mary herself would have had the right 
to perform the access.

A side note: we have military systems in mind, in which case 
availability needs are usually more important than the need to block 
unauthorized access. In our world, we would grant the same permissions 
to Jack and Mary from the beginning, and just ask Jack to not exercise 
his permissions until Mary dies. (In some cases we would mark the 
permissions of Jack as "emergency use only" to make it easier to monitor 
him, which would mean duplication of the rules.) In our case, we need to 
be agile, so we cannot risk that the computer is not aware of Mary being 
unavailable, and thus preventing Jack from using his permissions if he 
needs to. However, I can understand that the civilian use cases may be 
different.

Erik