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

[Erik Rissanen <erik@axiomatics.com>]

Hal,

I think this seems like a good start for such a protocol. I also think 
it makes sense to specify this assuming how the PAP knows which policies 
goes where, since it means different kinds of policy distribution 
algorithms can be layered on top of this.

Did you consider using the policy version attribute rather than a date? 
I am not sure what the implications are, but I am just noting that there 
is a version attribute, but no date attribute in the XACML schema.

/Erik

Hal Lockhart wrote:
> 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.
>
>