RE: [xacml] REST Profile - PAP Issues

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

I would use an optimistic concurrency model over an exclusive lock revision model.  

IOW, submit an indicator of what version your revision is based on (eg, HTTP entity tag), and if the current "tip" revision at the server does not match your base then the client needs to reconcile differences with the new tip revision and resubmit.

Accessing policies via REST is pretty straightforward.  The tricky part is the semantics behind POST for policy revision. If we can't find an abstraction that we can be confident will be compatible with an as yet undefined policy management policy/semantic, perhaps the best step for moving the REST profile along is to remove policy POST from the REST spec for the moment?

-Danny

Danny Thorpe 
Product Architect | | Quest Software - Now including the people and products of BiTKOO | www.quest.com 

-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@oracle.com] 
Sent: Tuesday, May 29, 2012 12:54 PM
To: Danny Thorpe; remon.sinnema@emc.com
Cc: xacml@lists.oasis-open.org
Subject: RE: [xacml] REST Profile - PAP Issues

How would you model operations like check in and check out?

BTW, I am starting to think it would be best to separate the policy management stuff from the much simpler decision request.

Hal

> -----Original Message-----
> From: Danny Thorpe [mailto:Danny.Thorpe@quest.com]
> Sent: Thursday, May 17, 2012 3:45 PM
> To: Hal Lockhart; remon.sinnema@emc.com
> Cc: xacml@lists.oasis-open.org
> Subject: RE: [xacml] REST Profile - PAP Issues
> 
> >>>>>>>>>
> > > 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