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

[Rich Levinson <rich.levinson@oracle.com>]

Hi Hal,

First, let me say I think it is a good first cut at laying out a foundation for this
PAP-PEP policy distribution protocol.

1. Couple up front clarifying comments first: Prateek I believe was actually referring
to section 5: Policies in the SAML Profile V2. Apparently the TOC needs updating
because it has it listed as section 4, but it looks like section 2.6 got promoted
to Section 3, whether rightly or wrongly is a little difficult to say. However, it is
section 4 in V1. I notice now that the V2 Policy protocol has evolved somewhat
from V1, although it appears the functionality is basically the same - my comments
below in item 4 are ref'ing V2.

2. We were going to ask about the date-time that you have in the Policy-Id (I copied
your follow-up email on it at end of this message for completeness, but as I read
it more carefully, I don't think that's the date and time that we are asking about).
It says in the core spec (5.1 PolicySet@PolicySetId and 5.22 Policy@PolicyId)
that "It is the responsibility of the PAP to ensure that no two policies visible to
the PDP have the same identifier".

Based on the above paragraph, my question is what is the date/time that you are
referring to that makes the PolicyId unique, and based on the quote above, is
it really necessary since the PAP is responsible to make sure they are unique
in any event?

3. On a more substantive note, one initial question I had going thru the proposal is
the relation between the actual PolicySets, Policys, PolicySetIdReferences,
and PolicyIdReferences, as compared to the "list of Policy Ids" returned by PDP
in step 2 of push and pull, and sent by PAP in step 1 of pull.

Since PolicySets can contain both PolicySets and Policys, and they all have unique
ids and they are all in one PolicySet, does the list only contain the top level Policy
or PolicySet or all the contained members. Also, if an admin decides to consolidate
Policys into a PolicySet (ex. in the Interop we provided both individual Policys
and PolicySets as well as the whole batch in one PolicySet) or to break things
up from combined to components, does this affect the lists that are sent?

4. Relation to SAML Profile: the profile has a xacml-saml:ReferencePolicies, which
appears to be a catch-all for any PolicySets or Policys not included in the
collection of Policys and PolicySets explicitly contained therein. In other words,
it appear the rules for the XACMLPolicyStatement in the profile require that
a "complete" set be sent with no loose ends. Also, from diagram Fig 1 p9 of V2,
it appears that PAP can also do a push and respond to a pull. (At least, it
appears that one could define some kind of SAML unsolicited Response
as implied is reasonable on lines 174-177 of V2 that encourages using
the XACML artifacts for exchanging info.)

I guess the bottom line on this item 4 is that when you get right down to
implementing your proposal, using this SAML V2 profile looks like
a pretty reasonable start in that direction.

In summary, for the above items, the only one that appears to me to
need some technical addressing is item 3 where I would like to
understand how these lists can be created without leaving room
for ambiguity as far as making sense within the context of a
collection of Policys and PolicySets.

5. One final item, which is probably more general than just this
policy exchange is where you mention "It is assumed that the PAP
knows what policies a given PEP should get by some unspecified
means." and follow it with a mention of "Targets". I think we need
to look at this issue more carefully to provide implementors
guidance and consider whether the current Policy and PolicySet
definitions contain enough information for identifying how to
divide up policies into domains or authorized access etc. It seems
to me that Targets may not be a reasonable way to do this in
general, since one can put almost anything in a Target. Maybe
this is a "best practices" issue?

    Thanks,
    Rich






Hal Lockhart wrote:

2E22E42D2E71B845B67F093A02B962DB0123C6D6@repbex01.amer.bea.com" type="cite">

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 (Issue62)

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
shouldhold.

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.


-------- Original Message --------
      

2E22E42D2E71B845B67F093A02B962DB0123C6D6@repbex01.amer.bea.com" type="cite">

Subject:	[xacml] Added Effective date/time to provisoining policy proposal
Date:	Wed, 10 Oct 2007 11:23:06 -0700
From:	Hal Lockhart <hlockhar@bea.com>
To:	<xacml@lists.oasis-open.org>

I forgot I had intended to provide support for an effective date/time
for a set of policies. The idea is that a set of policies can be marked
as taking effect at a future date time such as at midnight. The policies
can be distributed in advance and the PDP will continue to us the
current set of policies until the effective date/time arrives. A set of
polices with no effective date/time would default to go into effect
immediately.

For the Push Protocol, this simply requires adding an effective
date/time element to the batch.

For the Pull protocol, an effective date/time can be added to the policy
list response from the PAP. However, the use of this feature depends of
the PDP initiating the protocol in time to get the set of policies
before the effective date/time.

I have made the changes in the wiki to add this feature.

Hal