RE: [xacml] Outline of Policy Distribution Protocols (Issue 62)

["Hal Lockhart" <hlockhar@bea.com>]

I am going to guess that what you are referring to is Section 4 of the
SAML Profile.

The SAML-based policy request profile was never intended to be used for
provisioning. Its purpose was to allow a server to provide polices on a
per-request basis to a PDP with little or no non-volatile storage. It
provides no means to distribute a subset of available policies without
duplicates. 

As I have said repeatedly, I think the case of transferring ALL polices
can be easily covered using existing protocols, e.g. ftp. However, my
proposed design does permit the transfer of any subset, including all
policies.

Your question does raise some other points. Should the policies and
policy sets be delivered "naked" or wrapped in a SAML assertion? My
thinking was that these polices had already be vetted by a trusted PAP
and therefore it would be simpler and more efficient to send them
without a SAML wrapper. Message protection, if desired can be provided
by TLS or WS-Security as specified elsewhere. As a result of these
considerations I was not even planning to make this a part of the SAML
Profile, but a new free standing Profile.

So the short answer is that these are new protocols with different
functionality from the current policy query protocol.

Hal

> -----Original Message-----
> From: Prateek Mishra [mailto:prateek.mishra@oracle.com]
> Sent: Wednesday, October 10, 2007 12:58 PM
> To: Hal Lockhart
> Cc: xacml@lists.oasis-open.org
> Subject: Re: [xacml] Outline of Policy Distribution Protocols (Issue
62)
> 
> Hal,
> 
> do you view this material as replacing Section 5 or augmenting it? Or
do
> you plan for this to be independent of Section 5.
> 
> - prateek
> 
> 
> 
> > Here is an overview of a scheme for distributing policies. It is
> > designed to work with any version of XACML. If it seems reasonably
> > sound, I will create a Profile with specifics and Schema.
> >
> > I have also posted this text to the wiki under Issue 62.
> >
> > Hal
> > --------
> >
> > XACML Policy Distribution
> >
> > Assumptions
> >
> > There is a Policy Administration Point (PAP) which holds all the
> > policies for some domain. There are a number of Policy Decision
Points
> > (PDP) which retain in some local (typically non-volatile) storage
all
> > the policies it considers to make decisions. Different PDPs may use
> > different subsets of the policies held by the PAP. A PAP will
typically
> > serve a number of PDPs. Conceivably a PDP may get its policies from
> > several PAPs, however I am not aware of a motive for this usecase.
> >
> > This protocol is concerned only with the interaction between one PDP
and
> > one PAP. It is assumed that the PAP knows what policies a given PDP
> > should get by some unspecified means. In a real deployment, this
might
> > be based on manual configuration, some portion of the policies such
as
> > their Targets or by some other means. It is assumed that each PDP
has a
> > unique identifier which the PAP knows in advance.
> >
> > The protocol should make it easy to recover from failures of either
> > participant or the communications link. Also in most cases work done
> > prior to a failure should not have to be repeated. The protocol
should
> > make it possible for the PDP to determine that it has a complete and
> > consistent set of policies.
> >
> > All XACML Policies and Policy Sets contain an identifier. Different
> > policies can contain the same identifier, but they will have
different
> > date/times. The combination of Policy Identifier and date/time is
> > assumed to be unique. For the purposes of this discussion the Id &
> > date/time pair are called a Policy Id.
> >
> > Two different protocols are defined, a push protocol (controlled by
the
> > PAP) and a pull protocol (controlled by the PDP). Both protocols
have
> > different advantages and disadvantages. It is expected that each
will be
> > used in different environments.
> >
> > Push Protocol
> >
> > 1 Req. (Optional)  PDP -> PAP request policy update.
> >
> > This message will be useful in cases such as a PDP first starting
up.
> >
> > 2. PAP -> PDP request current policy list
> >
> > This can be sent in response to an update request or as an
unsolicited
> > message. A PAP might initiate the request because an Administrator
has
> > updated the policies.
> >
> > 2. PDP -> PAP response with list of Policy Ids currently held by the
> > PDP. Optionally the PDP can specify a maximum message size for
policy
> > updates.
> >
> > PAP compares the policies held with the list of policies the PDP
should
> > hold.
> >
> > 3. PAP -> PDP Policy update batch.
> >
> > The batch contains two kinds of items:
> >
> > A. Delete policy - specifies the Policy Id of a Policy to delete
> > B. Add policy - contains Policy or Policy Set to add
> >
> > (Batch mechanism TBD. Could use SPML batch function or WS-RM
sequence.)
> >
> > Each message in batch should be acknowledged. PDP should implement
> > atomic update. No action should be taken until complete batch is
> > received. Once batch is complete, policy evaluation should cease.
All
> > deletes and adds should be applied. Then evaluation should resume.
> >
> > Pull Protocol
> >
> > 1. PDP -> PAP Request current policy list
> > 1. PAP -> PDP response - list of current policy ids for that PDP
> >
> > PDP compares list with policies currently held. Policies to be
deleted
> > are noted.
> >
> > 2. PDP -> PAP Policy request - list of Policy Ids of policies to be
> > returned
> > 2. PAP -> PDP Policy response - Returns Policies and Policy Sets.
> >
> > PAP is allowed to send subset of Policies requested. If a requested
> > policy does not exist, an error must be returned identify the Policy
in
> > question. In this case, the PDP should go back to sending a request
for
> > the current policy list.
> >
> > PDP continues sending policy requests until all needed policies have
> > been received. Then the PDP stops evaluation, atomically adds new
> > policies and deletes obsolete ones, then resumes policy evaluation.
> >
> >