RE: [xacml] REST API -- finding a policy based on it's PolicyId

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

>>>>>>>>>>
-----Original Message-----
From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of remon.sinnema@emc.com
Sent: Friday, June 01, 2012 1:12 AM
To: cforster@us.ibm.com
Cc: xacml@lists.oasis-open.org
Subject: RE: [xacml] REST API -- finding a policy based on it's PolicyId

Craig,


From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Craig R Forster
Sent: Friday, June 01, 2012 1:19 AM
To: xacml@lists.oasis-open.org
Subject: [xacml] REST API -- finding a policy based on it's PolicyId

> In my view, a common use of the REST profile will be for the PDP to fetch policies from a PAP / policy repository. 

Danny has mentioned this as well. I countered that that seems to be a very inefficient way to go about it, and that it's more likely that the PAP would write policies to some sort of Policy Repository and that the PDP would query that repository. The representation of policies in the repository is likely optimized for querying by the PDP.

But if people think this is a good use of the REST API, then I'll add it as a use case to the profile.
<<<<<<<<<<<<

Without a standardized way to address a specific policy revision in one network request knowing only the policy ID and version (or version range) desired, REST is not a good use case for PDP -> repository access.  The REST enumeration mechanism is fine for discovery when you aren't sure what you're looking for but not for direct addressing when you know exactly what you're looking for (policy ID & version).

For my PDP case, I plan to either give the PDP intimate knowledge of the URI pattern so that it can "directly" construct URIs to fetch policies from the database using the REST API, or rely on a query mechanism as Craig mentioned to target specific policies. 

>>>>>>>>>>
> A key part of this process will be finding the URI of a policy based 
> on it's PolicyId/PolicySetId, as we've already determined that these two are separate (that is, one can't derive the URI from the PolicyId).
>
> Do we need to standardize a way to do this, something that's more 
> efficient than "list all policies, examine the returned Atom document 
> and find the one you want"? We could even limit it to the semantics of "get me the latest version of the policy with this identifier"...

That's a very good idea.

Unfortunately, neither RFC 4287 nor 5023 define filtering/querying of Atom feeds. So we can either cook up our own scheme, or use something like OData:
http://www.odata.org/media/30002/OData.html#thefiltersystemqueryoption
<<<<<<<<<<<

I'm leaning toward using ODATA query format in my project.  Still getting my head around it.

>>>>>>>>
> Perhaps something like:
> GET /authorization/policies?identifier=<policy id>&version=current

Yes, that would be our own scheme. I think this works best for the current use case, since it's such a simple one. 

However, I do foresee that we'll want to do more sophisticated filtering in the future. For instance, list all policies that target a given subject (to support Reverse Query-like operations).
<<<<<<<<

Another point in favor of using ODATA. ;>

>>>>>>>>>
> I imagine getting the latest version of a policy will be something 
> that policy authoring components will want to do as well. However, 
> neither of these scenarios may be possible as we've pushed the semantics of a version to the client (ie the server can't work out what 'current' means).

There is nothing in a policy that indicates that it is the "current" version. So the only thing we can use, is the version relative to other versions of the same policy. This means we need to compare version numbers, which is currently unspecified by the core spec, as Danny recently pointed out.
<<<<<<<<<

Agreed - the notion of "current" leads us back into the realm of policy management, deployment, policy revision workflow, etc.  "Current" can mean different things in different contexts. 

-Danny