MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: FW: [xacml] XACML Delegation/Administration Requirements
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]