OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


This is a bug. I looked at the 2.0 spec before I started, but didn't
check back when I wrote the protocol description. Version is what I had
in mind, not date. The point is simply to resolve to a unique policy or
policy set using the mechanism we already have. I will update the wiki.

Yes, I originally thought about some kind of mechanism for distributing
policies based on some aspect of their contents, but decided it was
better to leave that outside of standardization and simply assume the
PAP knows what goes where.

Hal

> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com]
> Sent: Thursday, October 11, 2007 2:16 AM
> To: Hal Lockhart
> Cc: xacml@lists.oasis-open.org
> Subject: Re: [xacml] Outline of Policy Distribution Protocols (Issue
62)
> 
> 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.
> >
> >



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]