summary of Frank's delegation proposal

[Anne Anderson <Anne.Anderson@Sun.COM>]

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
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692