Policy administration topics

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

We now have multiple work items that seem very related:

29. Policy Authority Delegation
31. Attribute Issuer as Subject
38. Policies for the Administration of XACML Policies

Do we really have one work item here:

  How does the PDP know if issuer I is trusted to issue policies
  about a particular combination of subjects, resources, and
  actions?

Use Model: I believe everyone agrees on the use model:

  The PDP's policy-retriever component tests whether to trust a
  given candidate policy by sending an XACML request describing
  the candidate policy to a Policy Administration PDP that is
  configured with policies describing which candidate policies to
  trust.

Proposal S: (Simon)

  I believe Simon's proposal is a pull model, where the PDP pulls
  policies as required from repositories or issuers:

  When the PDP's policy-retriever component tests whether to
  trust a given candidate policy, it constructs a Request that
  includes

  o Subject: the Issuer of the candidate policy (take the
    Issuer from the signature on the SAML Assertion encapsulating
    the candidate policy),
  o Resource: the actual <Target> element of the candidate policy as
    the value of a new Resource Attribute "policy-target",
  o Action: "issue policy"

  Define a new FunctionId that does an exact byte-for-byte match
  between normalized values for <Target> elements, and use this
  in writing policies describing which issuer Subjects can "issue
  policy" for given Targets.

  Issue: the model for how the set of applicable policies used by
  a PDP is constructed is not entirely clear.  Some possible
  models:

  1. The PDP is configured with a base PolicySet, and is just
     validating the components of its subtree as it retrieves
     them while doing evaluations.
  2. The PDP at any one time has a bag of candidate policies.  It
     periodically evaluates which ones to trust using the
     procedure above.  Out of the trusted policies, it then
     constructs the PolicySet and its subtree by matching up
     PolicyId#'s and PolicySetId#'s (these are assumed to fit
     together in some consistent way).
  3. The PDP at any one time has a bag of candidate policies.  It
     periodically evaluates which ones to trust as in #2.  The
     PDP is configured with a base PolicySet that has a specified combining
     algorithm.   Prior to evaluating Requests, all validated
     Policies and PolicySets are plugged into the base PolicySet
     as top-level components.

Proposal A: (Anne)

  This is a push model: Policy issuers push policies to a new
  Policy Administration API in the PDP, along with the Id of the
  Policy or PolicySet that the new pushed policy affects.

  Each PDP is configured with an initial Access Control PolicySet
  and an initial Policy Administration PolicySet.  The PDP
  validates each pushed policy by sending it in an XACML Request
  that is evaluated according to the current Policy
  Administration PolicySet.  If the pushed policy is validated,
  then the policy-administration component of the PDP makes the
  appropriate changes to the indicated Access Control PolicySet
  or Policy Administration PolicySet and their sub-policies.  Its
  two trusted trees of policies are stored in a secure cache.

  When validating a pushed policy, the Request from the
  policy-administration component includes:

  o Subject: the Issuer of the pushed policy (take the issuer
    from the signature on the SAML Assertion encapsulating
    the pushed policy).
  o Resource:
    - resource-id Attribute contains the PolicyId or PolicySetId
      of the Policy or PolicySet affected by this request
    - ResourceContent contains the pushed policy [not needed with
      delete-policy action]
  o Action: Possible actions are:
    - create-sub-policy under PolicyId x [in slot# y]
    - delete-policy id=x
    - replace-policy id=x
    - replace-policy-target id=x
    - replace-policy-combining-alg id=x

  Policies can express conditions on candidate policies by using
  XPath expressions to extract components of the candidate policy
  from the ResourceContent and place conditions on them using
  standard XACML functions.  A simple form of Condition could use
  the target-match function defined in Simon's proposal, so the
  degenerate form of this proposal is quite similar to Proposal
  S.

  Sample policy used by Policy Administration PDP: "issuers A and
  B can create sub-policies under PolicyId 3 so long as the
  sub-policy Target Resource is "abc".

  <PolicySet PolicySetId="1" CombiningAlgId="deny-overrides">
    <Target>any</Target>
    <Policy PolicyId="2" CombiningAlgId="deny-overrides">
      <Rule>
        <Target>
          <Subject>issuer A</Subject>
          <Subject>issuer B</Subject>
          <Resource>PolicyId 3</Resource>
          <Action>create-sub-policy</Action>
        </Target>
        <Condition>
          Resource/ResourceContent/Policy/Target/Resource/resource-id = "abc"
        </Condition>
      </Rule>
      ...
          
Proposal F: (Frank)

  I believe Frank proposes including the Issuer of a policy as a
  new classification, alongside the existing Subject, Resource,
  and Action.  When a PDP is trying to decide whether to trust a
  given policy, it will evaluate the policies that are applicable
  to that "Issuer".

  If I understand Frank's proposal correctly, I think it is the
  same as Proposal S or Proposal A.

Proposal P: (Polar)

  I did not actually see Polar work out his proposal, so I don't
  know how it differs from S, A, or F.

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