Re: [xacml] summary of Frank's delegation proposal

[Frank Siebenlist <franks@mcs.anl.gov>]

In my previous email i distinguished two different policy statements: an access 
control policy and an delegation/administration policy.

I grouped the delegation and administration together for simplicity.

You could distinguish two administrative policy statement:

* one that allows certain admins to manage the policy for certain targets,

* and another that allows certain admins to delegate the rights to manage the 
policy for a certain target.

In previous emails, I suggested that implementations could choose either to 
always allow admins to delegate the management rights they have, or to use a 
boolean flag in the admin policy statement that would indicate whether further 
delegation was allowed, or to use an integer to specify the maximum delegation 
depth, i.e. maximum length of the delegation chain.

Unlike with access control policies, it seems overkill to allow admins to speak 
on the management rights of other admins without having the right themselves to 
manage those same targets.

Would it be enough to add this clarification or did you have other concerns?

Regards, Frank.

(as admin and delegation policy statement are about policies about policies, 
maybe we should call them meta-policies ;-)




Daniel Engovatov wrote:

> Did we actually decide on whether "delegation" is the appropriate term
> to describe this proposal?
> 
> I would think this is something else, probably useful, but I would
> hesitate to call it "delegation"
> 
> Daniel.
> 
> 
> 
> -----Original Message-----
> From: Frank Siebenlist [mailto:franks@mcs.anl.gov] 
> Sent: Tuesday, May 18, 2004 9:50 PM
> To: Anne.Anderson@Sun.COM
> Cc: XACML TC
> Subject: Re: [xacml] summary of Frank's delegation proposal
> 
> Hi Anne,
> 
> Thanks for picking this up, and I couldn't have explained it better.
> 
> I just like to add some high level observations. Hopefully I won't
> confuse 
> anyone "more" with my attempt to clarify :
> 
> * as we know all too well, a request context plus a policy(-set)
> statement 
> yields a decision. If there is an issuer associated with a policy
> statement, 
> then that same issuer is associated with the decision.
> 
> * the combination of a decision plus the request context that yielded
> that 
> decision, can be seen as a policy statement itself where essentially the
> request 
> context is folded over the original policy statement, or the target is
> trivially 
> narrowed to the request context. This allows us to do the
> policy-chaining at 
> decision time (when we know the request context) for policies languages
> that are 
> too expressive, and allows us to use the word decision and policy 
> interchangeable as long as that associated request context is clear.
> Note that 
> "too expressive" means that we cannot chain the policy statements in
> general as 
> there is ambiguity and overlap in the rule outcome without the request
> context.
> 
> * there are two kinds of policy statement: access control and 
> delegation/administrative policies, APs and DPs. With a request context,
> they 
> yield access control and delegation/administrative decision, ADs and
> DDs.
> 
> * With a given request context for an authorization evaluation, we can
> create a 
> decision tree for each access control policy statement, where the
> end-leaves are 
> decisions that stand by themselves, and the nodes are decisions that
> depend on 
> the decisions of others. "Stand by itself" means that no other policy
> statements 
> can be found that speak to the validity of the stated policy, all
> available 
> policy statements yield a NotApplicable for that policy statement with
> its issuer.
> Furthermore, only the top level node of this decision tree would consist
> of an 
> access control decision node, while all nodes and leaves underneath
> would be 
> delegation/administrative decisions only.
> 
> For example:
> 
>          AD1,1          AD1,2     AD1,3
>          /   \            |
>       DD2,1  DD2,2      DD2,3
>       /   \
>   DD3,1  DD3,2
> 
> 
> The top level consists of three access control decisions (all not
> applicable 
> ones can-be/are discarded). All children nodes and leaves are 
> delegation/administrative decisions.
> 
> * The term "reduction" is used to transform a node with leaves to a
> single leaf, 
>   while the term "combinator" was used for the transformation of a set
> of leaves 
> into one.
> 
> Combinator example:
> 
>       DD2,1                              DD2,1
>       /   \        == combinator ==>       |
>   DD3,1  DD3,2                          DD3,1-2
> 
> 
> The general rules for combinators are the same as we have now, with the 
> following additions:
> 
> ** only leaves can participate in a combinator, so all nodes must first
> be 
> reduced to leaves before the combinator is executed
> 
> ** any leaf that is not a PDP decision can be discarded, or can be
> transformed 
> to a Not-Applicable decision issued by the PDP
> 
> ** the result of any combinator over an empty set of leaves is a
> NotApplicable 
> decision by the PDP
> 
> In other words, Combinators would still work as before, except that they
> would 
> only take decisions into account that were issued by the
> trust-root/owner/PDP, 
> and would discard (i.e. NotApplicable) any results from other issuers.
> 
> Reduction example:
> 
>    DD2,1                         DD2,1*
>      |       == reduction ==>
>   DD3,1-2
> 
> The general rules for reduction are:
> 
> ** if the original node's decision (DD2,1) was issued by the PDP, then
> the 
> leaf's decision (DD3,1-2) is irrelevant and discarded. This can be used
> as an 
> optimization to stop expanding the tree for PDP-issued decisions.
> 
> ** only nodes with a single leaf can be reduced, so all children nodes
> and 
> leaves have to be reduced and combined to a single leaf first, before
> reduction.
> 
> ** the reduced leaf-node (DD2,1*) will always be issued by PDP
> 
> ** the original node's decision before the reduction only becomes the
> reduced 
> node after the reduction if and only if the leaf was a Permit decision
> issued by 
> PDP. In all other cases, the reduced node's decision will be
> NotApplicable 
> (issued by PDP).
> 
> ---
> 
> Hope this helps, and hopefully Polar can use part of this email thread
> for his 
> write-up (hint, hint ;-)
> 
> Regards, Frank.
> 
> 
> Anne Anderson wrote:
> 
> 
>>For people who could not make the F2F, I thought I would
>>summarize Frank Siebenlist's proposal for delegation.  I was
>>pretty excited by it, and this it may be a good approach.  I
>>apologize to Frank if I am mis-representing his proposal!
>>
>>1. Associate an Issuer with each XACML policy that is visible to
>>   the PDP (i.e. not just in a SAML Policy Assertion).
>>
>>   A new, optional <Issuer> element would be added as a child of
>>   <Policy> and <PolicySet> to contain the Issuer identity.  The
>>   semantics of <Issuer> are that the named identity "says" that
>>   the <Policy> or <PolicySet> in which it appears is an approved
>>   policy of that identity.  If the element is missing, the
>>   Issuer is by default the PDP itself.
>>
>>2. Allow an Issuer identity to declare that some other identity
>>   has the right to issue policies of a given form.
>>
>>   The other identity is specified by a Subject with a new
>>   SubjectCategory meaning "can issue".
>>
>>3. An additional step is added to policy evaluation to find a
>>   chain of applicable policies such that Issuer = PDP.
>>
>>   a. If the applicable policy has Issuer = PDP, then stop and
>>      return the result of evaluating that policy.  If there are
>>      no applicable policies, return "Not Applicable".
>>
>>   b. Otherwise, for each applicable policy, create a new Request
>>      equal to the original request except that it has an
>>      additional <Subject> with SubjectCategory="delegate" and
>>      subject-id equal to the Issuer of the applicable policy.
>>
>>   c. Find all policies applicable to the new Request.  If any
>>      result in "Permit", repeat starting with 3a.
>>
>>Simple Example:
>>
>>  Policies are:
>>    I is "Issuer"
>>    D is a Subject with SubjectCategory="delegate"
>>    S is a Subject with SubjectCategory="access-subject"
>>
>>  1. I=PDP
>>     Permit Subject D="Manager1" to do Actions A to Resource R
>>
>>  2. I=Manager1
>>     Permit Subject S=Manager2 to do Action A to Resource R
>>
>>  ROUND 1:
>>
>>  Request: Can Subject Manager2 do Action A to Resource R?
>>
>>  Policy 2 applies, and result is Permit, but Issuer is not PDP.
>>
>>  ROUND 2:
>>
>>  New Request: Can Subjects D=Manager2 and S=Manager2 do Action A
>>     to Resource R?
>>
>>  Policy 1 applies, result is Permit, and issuer is PDP.  Return
>>  Permit.
>>
>>  Notes:
>>
>>  Policies that include SubjectCategory="delegate" could be
>>  constructed to limit the set of applicable Subjects with
>>  SubjectCategory="access-subject", could apply to many
>>  delegates, could apply to many resources and actions, etc.
>>
>>  This delegation chain is only one policy long, but there could
>>  be long chains.
>>
>>  Policies might mix delegation permissions with non-delegation
>>  permissions.  For example, some rules might apply to a
>>  particular Subject with SubjectCategory="delegate", whereas
>>  others might apply only to access-subject Subjects.  A single
>>  rule could apply to a mixture.
>>
>>Things we did not finish thinking through (or that I did not hear
>>conclusions to):
>>
>>- Do all chains have to be evaluated every time, or is there some
>>  caching that could be done?  PDP could have limit on how long a
>>  chain could be and could test for cycles.
>>- How are the new policies issued by entities other than the PDP
>>  inserted into the policy evaluation?  Could they be passed
>>  along with a Request, and possibly limited to use with that one
>>  Request?  Is there some new PDP API?
>>- How do "Deny" policies fit into this model?
>>- Are any new combining algorithms useful or required?
>>
>>Anne
> 
> 

-- 
Frank Siebenlist               franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory