RE: [xacml] REST Profile - PAP Issues

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

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