RE: [xacml] REST Profile - PAP Issues

[Hal Lockhart <hal.lockhart@oracle.com>]

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

Yes it is. In Core section 5.14 under [PolicyId] it says: 

It is the responsibility of the PAP to ensure that no two policies visible to the PDP have the same identifier.

The Cohort is nothing more or less than the policies visible to the PDP.


> 
> > 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?
> 
Only if you consider the PAP to contain the active policies being used by a PDP. My impression was that you saw it as a kind of repository for policies under development. This is not a huge point and I could live with the restriction, I just wanted to clarify what the restriction in XACM Core is.

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

I am saying that if the only way I have to find a unique id is to scan the list it will be easy to miss one or misread the value. If I use an algorithm to select an unused one, what about a race condition with other policy editors using the same algorithm?

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

In the case I mention, is does the PAP require that a policy being updated retain the same ID? Is the PAP required to check for duplicates in all the other policies? 

I don't necessarily see a problem, I just want the behavior of the PAP to be completely specified.

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

Just needs to be spelled out.
> 
> 
> > 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.

Perhaps you are right, but I cannot imagine updating a policy in production without regression testing it as a part of a Cohort. Perhaps I am miss interpreting the document, but the idea of creating a new policy, testing it in isolation and putting it directly in production seems very risky.
> > 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.

I agree with splitting the up and I welcome your interest.

Hal