[xacml] comments on LDAP profile for distributing XACML policies

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

Here is the first of my long-standing Action Items.  Sorry it
took so long, Tim!

Title: Comments on "XACML LDAP profile for distributing XACML
       PolicyStatements", slide set dated July 2002, presented at
       July 2002 XACML Face-to-Face
Author: Anne Anderson
Version: 1.2, 02/12/16 (yy/mm/dd)
Source:  /home/aa74233/projects/xacml/SCCS/s.Response_Tim_LDAP.txt

The Data model looks fine (modulo changes in current spec, such
as multiple Attributes per Action), except that I think there may
be multiple repositories in use by a given organization (see
below).

I think the "Procedure" described is fine other than expectation
that the resulting set should have only one member.

My primary objection is that I think it extremely unlikely that
an organization's policies will be structured such that only one
Policy will apply to a given Request.  Ensuring that this is true
would require infinitely capable Policy System Administrators, a
resource that is in short supply right now.  I also think it an
unnecessary restriction on actual use cases to impose this
requirement.

Here is my model for how Policies are developed and accessed:

- various corporate entities will develop policies independently
  of each other: Human Resources, Real Estate Management,
  Marketing, Sales, Software Engineering, ...  These policies may
  be published to one or more repositories.  A given Request must
  satisfy all applicable policies from all these entities.

- a PRP will be configured with a template PolicySet that
  probably has a Deny-overrides combining algorithm.  The
  template may have no Policies in it.

- a PRP will be configured with information about the various
  repositories that store policies that it must search.  If all
  corporate entities publish their policies to a single
  repository, then the PRP will be configured to search that one.
  If there are various repositories to which entities publish,
  then the PRP will be configured with all of them.

- Policies in a given repository are "indexed" in various ways.
  Typically, there will be multiple indices, each based on some
  MatchId on some Attribute.  Also, some policies will not be
  indexable for any given index (AnySubject, match function not
  indexable), so there will be a bucket of "non-indexed policies"
  that will always be returned in response to a specific query.

  Given a Request, multiple queries will be made to the
  repository, each based on one of the Attributes in the Request
  that is an indexed Attribute.  The set of potentially
  applicable policies will be the intersection of the sets
  returned from each query.  Whether the multiple queries and the
  intersecting are handled by the PRP or by the Repository will
  depend on the functionality of the Repository and its APIs.

  PDP           Policy Retrieval Point              Repository

  --Request---->                ----Attribute,Value,MatchId--->
                                <---matching Policies---------
                                ----Attribute,Value,MatchId--->
                                <---matching Policies---------
                                ----Attribute,Value,MatchId--->
                                <---matching Policies---------
                                ----Attribute,Value,MatchId--->
                                <---matching Policies---------
                                ...                  
                       [compute intersection]
                       [insert intersection into template]
 <--populated template---

  The returned intersection of matching Policies is a superset of
  the Policies that are actually applicable to the Request.  This
  is because the indexing will rarely be fine-grained enough to
  retrieve only those policies whose Target elements match a
  given Request.  Some organizations will index only on common
  Subject Attributes, for example.  Some organizations will index
  only on equality-type MatchId functions.  Few organizations
  will index on every Attribute and every MatchId that may appear
  in a Policy Target.

The PRP inserts the intersection of "matching" policies into its
template PolicySet, and returns the populated template to the
PDP.

The PDP will evaluate the PolicySet, finding many of the included
Policies to be NotApplicable (due to the incompleteness of
indexing).  The PDP MUST fully evaluate all Target elements in
each Policy, since it can not depend on the PRP to have presented
only applicable policies.  The PDP uses the combining algorithm
that was part of the PRP template to "merge" the various policies
that it must apply.