Re: [xacml] REST API follow up

[Craig R Forster <cforster@us.ibm.com>]

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="">1"/>
    <content type="application/xacml+xml" src="">
    <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? 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.
2. Define clearly in the spec which one takes precedence in each case.
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.

Apologies if this has been answered in previous discussions.

Regards,
Craig

-------
craig forster | technical lead, tivoli security policy manager
cforster@us.ibm.com
-------

Danny Thorpe ---05/31/2012 02:04:27 PM---Follow ups from today's call: In earlier email I expressed concern about leaving version semantics u

From:	Danny Thorpe <Danny.Thorpe@quest.com>
To:	"xacml@lists.oasis-open.org" <xacml@lists.oasis-open.org>, "remon.sinnema@emc.com" <remon.sinnema@emc.com>,
Date:	05/31/2012 02:04 PM
Subject:	[xacml] REST API follow up
Sent by:	<xacml@lists.oasis-open.org>

---

Follow ups from today’s call:

In earlier email I expressed concern about leaving version semantics up to the client, that different clients may implement conflicting client-side versioning semantics. Given the policy containment model defined in the core XACML spec, I have not been able to come up with an example of two conflicting client-driven versioning schemes. So, I withdraw my concern about leaving versioning of policies up to the client.

I’m fine with saying the client is responsible for updating the policy version when POSTing a revision to the REST API. The server’s only responsibility is to verify that the policy ID + version is unique within the set of policy revisions it owns. PUT modifies an existing policy in-place, POST creates a new revision of the policy uniquely identified by policy ID + version string.

For its intended purpose of representing CRUD operations, the REST API is sufficient. There are many higher level questions about policy management left to discuss, but these all seem to be primarily organizational issues independent of the REST API’s simple CRUD interface. When posting a revision to a policy via the REST API, does that immediately impact a PDP? Does the repository contain all policies or only a selected subset of policies relevant to some use? These are outside the scope of the REST API itself. We’re not defining the system or the server, we’re just defining a CRUD interface.

The only unresolved discussion point in my mind is the matter of whether policy references must be fully resolvable when a policy revision is POSTed to the server. I believe the current proposal states that all policy references must be resolvable and validated or the server must reject the post. I understand the Admin profile requires “late bound” policy references which may only be resolvable in the context of a particular auth request.

From a relational integrity standpoint, it seems worrisome to accept policies without validating their outbound references. However if the Admin profile actually requires storing policies which contain references that cannot be resolved out of context, we may not have much choice here.

Thoughts?

Is there a way that the client can indicate when POSTing an update that this policy is an Admin policy and reference validation should be relaxed? This would allow us to maintain relational integrity checks for “normal” policies and suppress them for Admin policies.

-Danny

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