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

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

> 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?
> 

As mentioned previously, this is a bug which I will fix. I intended to
use policy version.

> 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?
> 

This is an excellent question and on general principles ought to be made
definite in the spec. However, notice that it doesn't actually make any
difference as long as the PAP is consistent. In other words, the PAP
says I have some boxes and here are the labels on them. The PDP simply
remembers what the labels are and either reports what it has or asks for
what it does not have. 

That said, I would be in favor of identifying each policy and policy
set. (A reference is just a pointer to a policy or policy set. We don't
need to distribute them.) I have always rejected the notion that a
policy set actually "contains policies". To me it is just a place to
define the combining alg and share Target definition and so forth.
However I don't feel strongly, so if people feel strongly that we should
use an id to refer to a policy set and any contained policies and policy
sets, I can live with that approach.


> 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.
> 
I am not sure I understand most of this, but I will take a look at the
latest draft of the SAML profile. In any event I am coming tobelieve I
need to support distributing both wrapped and unwrapped policies.

> 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?
> 

Well this is an area where there is a lot of potential for innovation
and product differentiation. The idea is to standardize the wire
protocol for interoperability, not design somebody's product for them.
;)

But here are a few ideas about how it could be done.

1. The simplest scheme (at least that I can think of) is that the UI
which allows admins to creates policies also provides a mechanism which
allows the admin to specify what PDPs should get what polices. This
could be done individually (sounds inefficient) or by grouping PDPs in
some way.

2. The admin could be allowed to define some templates to apply to
targets in policies in order to determine which PDPs get them. For
example, each PDP might handle decisions with resource names that
contained certain dns names. Say PDP1 gets policies pertaining to
*.factory.example.com and PDP2 gets policies pertaining to
*.marketing.example.com.

3. Policy identifiers could be chosen to indicate something about which
PDP gets a given policy.

In all cases, the idea is not to standardize this part, just the
protocol for moving the policies from PAP to PDP with reasonable
efficency.

Hal