RE: [xacml] REST API follow up

[<remon.sinnema@emc.com>]

Craig,


From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Craig R Forster
Sent: Thursday, May 31, 2012 10:56 PM
To: Danny Thorpe
Cc: Sinnema, Remon; xacml@lists.oasis-open.org
Subject: Re: [xacml] REST API follow up

> I'm still a little confused in general about the relationship between data that exists both in the PolicySet/Policy 
> and the URI -- namely, the PolicySetId/PolicyId and the Version.
>
> For example, the draft seems to indicate that the PolicySetId is not part of the URL -- the server would maintain a 
> mapping and present that in the <entry> for a policy:
> <entry>
>    <id>urn:oasis:names:tc:xacml:3.0:example:SimplePolicy1</id>
>    <title>Medi Corp access control policy</title>
>    <link rel="alternate" href="/authorization/policies/1"/>
>    <content type="application/xacml+xml" src="/authorization/policies/1"/>
>    <summary>Medi Corp access control policy</summary>
>  <entry>
>
> So, what happens if someone POSTs a new version of "urn:oasis:names:tc:xcaml:3.0:example:SimplePolicy2" to 
> /authorization/policies/1 as it exists above? 

In a RESTful system, URIs identify resources. In XACML, policies are identified by PolicyId. Since equality is transitive, both identification methods must be consistent. IOW, if the same URI is used, then we're talking about the same policy, which means that the same PolicyId must be used. 


> Similarly, the Version is (optionally) part of an XACML policy. So what happens if someone POSTs a policy with "v1.0" 
> to the URL /authorization/policies/1/v2.0 ?
>
> I see two possible options:
>
> 1. Return a 409 Conflict, with a clear message saying what they've done wrong. If we do this, I think the spec needs 
> to define these error conditions and responses.

Of the three you mention, I like this one best.


> 2. Define clearly in the spec which one takes precedence in each case.

This violates the expectation that equality is transitive.


> 3. Only allow POST to the base /authorization/policies/ URL and have the server read the ID and version from the sent 
> policy, returning the path of the new or updated policy in a Location header.

This violates the expectation that updating is idempotent and therefore uses PUT rather than POST.


Option 4 is to return 400 Bad Request, since the request parts (URI & body) are inconsistent. I like this option best.


> Apologies if this has been answered in previous discussions.

Not at all, good point to bring up.


Thanks,
Ray