-----Original Message----- From: xac...@lists.oasis-open.org [mailto:xac...@lists.oasis-open.org] On Behalf
Of Hal Lockhart Sent: Wednesday, May 16, 2012 3:30 PM To: xac...@lists.oasis-open.org Subject: [xacml] REST Profile - PAP Issues

I have a number of different kinds of comments about the REST Profile and Media
types which will post separately to allow the discussion to take place in
distinct threads.

As I said on the last call, whereas the Access Decision functionality has an
existing model (the SOAP-SAML protocol) which we may take as a point of
departure to replicate or simplify, the policy management features break new
ground. The previous work I have done in this area appears in the wiki item #62
here: http://wiki.oasis-open.org/xacml/IssuesList

The focus of my prior work was on policy distribution (provisioning). The REST
Profile tackles the Policy Editor to PAP interface, so they may be completely
independent problems. However I would like to survey the entire landscape and
decide what to provide in the REST Profile in light of that.

Here is a brief summary. I have defined the concept of a Policy Cohort, which is
a set of policies (and/or policy sets) which are intended to be in force at a
given time at one or more PDP. A cohort is the unit of testing and distribution
of policies. When a PDP evaluates its policies, they consist of a single
<PolicySet>, however the top level <PolicySet> may be virtual. Further the use
of Admin policies means that there may be holes in the tree which will be filled
by policies provided at decision time for the duration of that decision and thus
are not part of the cohort. (Although probably part of the testing)

It seems to me that Policy management has two general phases: creation and
distribution. Creation involves creating, modifying and testing policies and
Cohorts. Distribution involves creating schedules for every PDP identifying what
Cohorts will be in effect at what times and physically distributing the Cohorts
to the deployed PDPs in advance of them becoming in force.

It seems to me that policy creation is similar to software development and
probably should involve similar tools. For example, it seems useful to be able
to check out, edit, fork, merge, compare, define Cohorts, unit test (one
policy), system test (a Cohort), check in and stage to be distributed. (We need
to decide as a matter of terminology whether to consider the staging point to be
apart of the PAP or a distinct architectural entity.)

In particular, one aspect of XACML policies which creation tools should support
is Policy ID and Policy ID Reference. XACML Core says that policies visible to a
PDP must have unique IDs. In my terminology, no Cohort can contain policies with
the same id. XACML also supports a versioning and sub versioning scheme which
allows references to be to a specific (minor) version or the latest (minor)
version. Given that, it seems like when you change a policy, particularly one
which has previously been in effect, you might want to increase its version
number and keep the old version around, rather than deleting it. It might also
be useful for the policy creation tools to generate policy IDs according to some
organizational template and prevent race conditions between users simultaneously
creating different policies.

Given this background, I am not sure how useful the functionality proposed in
the REST Profile will be. I grant that having a central point where policies can
be collected and inspected and compared could have value, but it seems to me to
be somewhat apart from the core tasks of creating and distributing policies.

Specific comments on wd 03:

Section 2.2.3 says creating policies with duplicate ids gets a 409. I see a few
issues here. First as I mentioned, the constraint is on a Cohort. There might be
convenient to have duplicate policy IDs in a PAP. Further, having to scan a list
of 100 or so policies to determine what a unique ID would be seems inefficient
and error prone. Then there is the issue that policies have an ID and a URI.
What if I have policy 22 at URI X and policy 23 at URI Y and I update URI X with
a new policy 23?

The next sentence says that creating a reference to a non-existent policy also
gets a 409. I can see at least 3 problems with this. 1) It is often inconvenient
when doing things of this type to be constrained to create things in a certain
order. 2) Dangling references are explicitly allowed when Admin policies are
supported. 3) The PAP will have to understand the XACML reference semantics
(exact vs. newest) in order to enforce this.

Overall, I don't see that much benefit from the proposed PAP functionality, but
I won't oppose it if others do see value. However, I would object if the
implication is that what is being managed is the policies currently in force at
some PDP. Updating policies on the fly seems like a recipe for disaster, but if
the polices in the PAP are not the ones currently in force, then I see little
probability that the PAP functions and PDP functions would be implemented in the
same software component.

As a final note, I am still interested in the policy distribution problem and
would like to specify something there, whether REST or SOAP based (or both).