MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xacml] clarifications/questions for worklist items 26, 29 and32
Polar Humenn wrote:
> ...
>>>29. Policy Authority Delegation
>>>
>>> We had a number of questions about this. It needs
>>> clarification. Issues:
>>>
>>> a. Define "domain". What does it correspond to?
>>> b. Could this be solved using a subject-domain or
>>> resource-domain attribute that the PEP should include in its
>>> Request, and that policies could match on?
>>>
>>> Wait for Frank to provide clarification before putting on F2F
>>> agenda.
>>>
>>> F2F: not until/unless Frank clarifies, but then possibly
>>
>>I have the feeling that all the "delegation" related items will be solved when
>>we tackle the "right of a subject to administer policy for a certain target".
>>
>>I reworded the description in item#29:
>>
>>29. Policy Authority Delegation
>> The ability to express in a policy rule that a certain authorization
>>authority is allowed to administer access control policy for a certain target.
>
>
> Isn't this just straightforward application of XACML policy to a
> "administer access control policy" action for a certain target?
More or less ... but we don't seem to have a placeholder for policy issuer: if I
want to express that John can administer the action=read on resource=abc for
Subject=Mary, then what is "John", and where do I match on "John"?
I have the feeling that we may need a specific policy-set/policy/rule issuer...
> Sorry Frank, but I'm having a hard time parsing the following description.
>
>
>>The evaluation for a certain target should probably yield "Indeterminate" or
>>"Not Applicable" (?) according to the local policy,
>
>
> Why *should* it yeild Indeterminate or Not Applicable?
>
>>it should yield "Permit" for the right of an authorization authority to
>>administer the policy for that target, and either the authorization
>>query to that authorization authority's PDP should yield "Permit" or the
>>evaluation of the pushed access control assertion by that authorization
>>authority should yield "Permit". If the local policy yield either
>>"Permit" or "Deny", the foreign authorization authority doesn't have to
>>be considered.(?)
>
> Okay now I am afraid, I'm lost. Do you have a specific use case for this
> one that we can see what your requirements are?
Sorry, my wording may have been a bit terse.
I was trying to point out the consequences of having multiple authorization
authorities (AA), and what kind of combinators you would need to resolve any
ambiguity.
The rules that seem most straight forward are that if you have a number of AAs
on the same level, then you should have a deny-overwrites combinator as you
"value" each of the AA's equally, and taking the safe route makes sense.
If you delegate admin rights to an other AA, then giving the ability of this
second-level AA to overwrite explicit access control policy doesn't feel right.
So, if the authorization decision of the AAs on the same level yields an
explicit permit or deny, we do not have to consider the policy of any further
delegated admin rights.
As a consequence, the policy of an AA would only become important if the lower
level AAs indicate that they do not want or can not make explicit authorization
decisions on the target under consideration: only after the combined policy
evaluation on the same level yields Indeterminate or Not Applicable, the next
level of AAs should be considered.
In short, it comes from the observation that you do not want to give anyone else
the right to over-rule your own explicit policy.
For example, if Marc's local/default/preferred policy states that John is
allowed to administer the action=read for subject=Mary and resource=abc, and
Marc's own policy explicitly denies or permits Mary read-access to abc, then it
doesn't matter what John's policy evaluates to.
However, if Marc's own policy doesn't evaluate to any explicit permission for
the mary/abc/read target, then it becomes important what John has to say about
that target.
Hopefully this clarifies some... a white board and the upcoming F2f may help.
Regards, Frank.
--
Frank Siebenlist franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]