Delegation, Policy Administration, and Trust in XACML

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

Here is a perspective on delegation and how it fits into XACML.
I think this helps clarify the requirements for handling policies
about policies (policy administration policies), as well as what
it takes to support delegation (one subject who is allowed to do
something can delegate to another subject the permission to do
that something).

1) The XACML PDP currently is completely independent of the
   authentication layer used to establish trust in policies and
   attributes.  A PDP is assumed to be configured with some set of
   trusted authorities, and only attributes and policies from those
   authorities are trusted.

   It is possible and appropriate to have the authentication layer
   use its own XACML policy to control its own actions.  For
   example, an XACML policy used by the authentication layer might
   say:

      Subjects X, Y, and Z can issue Attributes for AttributeIds A,
      B, and C.
      Subjects L and M can issue Policies.

   In these policies, the "action" is "issue", and the resource is
   an AttributeId (or "any Attribute") or a Policy[Set]Id (or "any
   policy").

2) There is no way currently for an XACML Request Context to
   affect the policies used by the PDP.

   We support "intermediary-subject" as a Subject Category, so
   policies can place conditions on who the intermediaries are,
   but there is no way for a subject who is currently identified
   as an "access subject" in a policy to make a request to the
   PDP that will add a new "access subject" where the original
   subject is now an "intermediary subject".

The important point is that, currently, there is no way for
information in a Request Context to affect the actions of the PDP
or its authentication layer directly.  A PDP does not
"understand" any action or resource attributes, so does not
"understand" that permission to, for example, "issue" X means the
PDP's authentication layer should accept X.

We need to decide whether there will be some distinguished set of
Request Context actions that an XACML PDP will "understand" and
act on.  We might define a "issue" action as follows:

  Request Context:
     Subject: S
     Resource:
        Subject: S'
        Resource: R
        Policy: P [optional]
     Action: "issue"

     where "R" is a set of PolicyIds, PolicySetIds, AttributeIds,
     "anyPolicy", or "anyAttribute".

  When the PDP encounters the "issue" action in a Request
  Context, it performs the following actions:

  1) Verify that the authentication layer already allows S to
     issue anything in the set R.  If not, return "Deny".
  2) Instruct the authentication layer to add S' as trusted to
     issue anything in the set R [subject to the XACML policy P,
     if supplied].  Return "permit".

Another "PDP-understood" action might be "delegate", but I think
this is harder to define.  The following is a possible approach.

When the Action in a Request Context is "delegate", then the
Resource in the Request Context would specifies a delegatee
subject, a delegated resource, a delegated action, and an
optional Condition on the delegation.

The PDP would first verify that the requester is allowed to
perform the delegated action on the delegated resource.  It would
then verify that the delegatee subject is not explicitly denied
performing the delegated action on the delegated resource.  If
either of these tests fails, the PDP returns "deny".

If none of the tests fails, the PDP would augment (using
deny-overrides) its current top-level PolicySet with a new Policy
having:
  with one "permit" Rule
  Target Subject is the delegatee subject
  Target Resource is the delegated Resource
  Target Action is the delegated Action
  Condition is the delegation condition, if any.

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