RE: [xacml] REST Profile - PAP Issues

[Danny Thorpe <Danny.Thorpe@quest.com>]

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

Yes, there will be multiple documents in the repository associated with the same policy ID.  The policy ID alone is not the complete identity of a policy document.  The policy ID + the policy version is the complete identity.  You will have multiple versions of the same policy ID running around in the same repository that are distinguished and unique by version number.

In database terms, your policy repository primary key is not PolicyID.  It's PolicyID + PolicyVersion.

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

If the only way you have to find a unique id is to scan a list, you have much larger problems. ;>  I agree with Remon - generating unique ids at cloud scale is a well understood problem with a variety of different solutions.  

I think it's sufficient to say that a POST of a policy document to the REST API will generate a unique (implementation defined) ID at the server and return the unique ID in the response.  How the unique ID is created or procured or communicated to the rest of the data center is beyond the scope of this discussion.

Since a policy is not fully identified by its ID alone, we may need to distinguish between creating an entirely new policy from scratch versus creating a revision of an existing policy (same policy ID, different version number).  I'll take this up in a separate email.

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

This shouldn't present a serious order-of-creation problem since Xacml already requires that the policy reference tree be strictly acyclic.  Persist all the referenced policies before the referee (recursively) and the order should be fine.

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

I agree that the first priority of the REST API should be to operate on coherent data. We can always add entropy later. :>

 
> 
> > 2) Dangling references are
> > explicitly allowed when Admin policies are supported.
> 
> I'll have to look into that.
> 

True.  Late binding. Always entertaining. :>

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

The REST API should allow for an implementation to express a staging or process workflow around policy creation, revision, testing, approval, deployment, and retirement, but I don't think that workflow definition should be part of the REST API.  I would expect that such a workflow would use the REST API, not the other way around.

One way to express such a workflow would be to set up a different independent PAP for each distinct stage in the workflow.  Policy development and testing happens on PAP.Staging. PAP.Staging is only accessible to PDPs used for testing, not accessible to production PDPs. After the workflow for policy revision, testing, and approval has been completed, the policy/policyset/cohort are copied to PAP.Production, where they are accessible to the production PDPs. PAP.Production is very restricted in who can post changes to that repository - PAP.Staging less so. How and when the PDPs discover and begin to enforce the revised policies is also beyond the scope of the REST API.

All of that can be done using the simple "PDP production oriented" REST API as sketched out.  (subject to version management in the next email)

-Danny