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: 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).

Hal


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