RE: [xacml] REST Profile - PAP Issues

[<remon.sinnema@emc.com>]

Hal,


> -----Original Message-----
> From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On
> Behalf Of Hal Lockhart
> Sent: Thursday, May 17, 2012 12:30 AM
> To: xacml@lists.oasis-open.org
> Subject: [xacml] REST Profile - PAP Issues
> 
> 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

Thanks, I will take a detailed look at this.


> 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'm working on a Platform-as-a-Service. Access control in this platform will be based on XACML. The API to the platform is RESTful, so I need a RESTful way to administer policies. The REST profile gives me this, which is *very* valuable to me. Given all the buzz around APIs these days, I doubt I'm the only one.

I understand that this is just a first step and we may do many more complex and more valuable things, like policy distribution. But I would urge us to get something out there rather quickly, so that we can experiment with it and get feedback based on real-world usage. The world is moving fast and we risk being left behind.


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

It is in your cohort proposal. It's not in the current core spec, since that doesn't even contain the concept of a cohort.


> There might be convenient to have duplicate policy IDs in a PAP. 

Only as an intermediate step, since the core spec forbids duplicate policy IDs to be in effect at the same time. So if we're not including any intermediate steps (like policy distribution), then having duplicate policy IDs is simply forbidden by the core spec, right?


> Further, having to scan a list of 100 or so policies to determine
> what a unique ID would be seems inefficient and error prone. 

I don't see why it would be error prone.
As for inefficient, that's an implementation detail. Also, it is a well understood problem, with well understood solutions. And 100, well, that's just not a lot at all.


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

In a RESTful system, URIs are opaque, one should not care what they look like (as long as they are in fact unique). There need be no relation between policy IDs and URIs, so I don't see any problem here.


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

I'm starting to think that with your cohort idea, we have two kinds of administrative interface. One where you build up your cohort, which may be temporarily in an invalid state, and one where the PDP gets its policies from, which must not be in an invalid state. I'm talking about the latter, but I have a feeling that you're talking about the former. Since the former is not part of the XACML architecture as shown in the core spec, I propose we give it a different name, so that it's always clear what we're talking about.


> 2) Dangling references are
> explicitly allowed when Admin policies are supported. 

I'll have to look into that.


> 3) The PAP will
> have to understand the XACML reference semantics (exact vs. newest) in
> order to enforce this.

Why is that a problem?


> 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

That's a bit strongly worded. Every application I know of (incl. operating systems and databases) does things this way, so it can't be that bad.
That's not to say that I don't see value in a staged approach; I do.


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

I don't think it should be part of the REST profile, since, like you mentioned, there could be a SOAP interface as well.
Also, I don't think the REST profile should be stalled because of it, since there is functionality in the core spec available now, that the REST profile addresses and that is valuable.

Having said that, I'm interested in pursuing the policy distribution topic as well.


Thanks,
Ray