OASIS eXtensible Access Control Markup Language (XACML) TC

  • 1.  REST API follow up

    Posted 05-31-2012 19:02
    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  


  • 2.  Re: [xacml] REST API follow up

    Posted 05-31-2012 20:58

    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:SimplePolicy 2 " 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





  • 3.  RE: [xacml] REST API follow up

    Posted 05-31-2012 21:58
    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


  • 4.  RE: REST API follow up

    Posted 05-31-2012 22:54
    Danny, From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Danny Thorpe Sent: Thursday, May 31, 2012 9:02 PM To: xacml@lists.oasis-open.org; Sinnema, Remon Subject: [xacml] REST API follow up > 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. I've added a section about different types of PAPs and how they may respond differently. That should make the server's behavior sufficiently underspecified to allow for both scenarios, while still providing useful interop possibilities. Let me know what you think. Thanks, Ray


  • 5.  Re: [xacml] RE: REST API follow up

    Posted 05-31-2012 23:09

    My opinion on this is that the core specification clearly states what to do when a PolicyIdReference or PolicySetIdReference can't be resolved:

    If resolving the reference fails, the reference evaluates to “Indeterminate” with status code urn:oasis:names:tc:xacml:1.0:status:processing-error.

    Let clients of the PAP upload policies as they see fit, and let the runtime resolve the references and return Indeterminate if the references can't be resolved.

    Regards,
    Craig

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

    ---05/31/2012 05:54:49 PM---Danny, From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Danny Thorp




    From:
    <remon.sinnema@emc.com>


    To:
    <Danny.Thorpe@quest.com>,


    Cc:
    <xacml@lists.oasis-open.org>


    Date:
    05/31/2012 05:54 PM


    Subject:
    [xacml] RE: REST API follow up


    Sent by:
    <xacml@lists.oasis-open.org>




    Danny,


    From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Danny Thorpe
    Sent: Thursday, May 31, 2012 9:02 PM
    To: xacml@lists.oasis-open.org; Sinnema, Remon
    Subject: [xacml] REST API follow up

    > 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.

    I've added a section about different types of PAPs and how they may respond differently. That should make the server's behavior sufficiently underspecified to allow for both scenarios, while still providing useful interop possibilities. Let me know what you think.


    Thanks,
    Ray


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
    For additional commands, e-mail: xacml-help@lists.oasis-open.org






  • 6.  RE: [xacml] RE: REST API follow up

    Posted 06-01-2012 07:44
    Craig, From: Craig R Forster [ mailto:cforster@us.ibm.com ] Sent: Friday, June 01, 2012 1:08 AM To: Sinnema, Remon Cc: Danny.Thorpe@quest.com; xacml@lists.oasis-open.org Subject: Re: [xacml] RE: REST API follow up > My opinion on this is that the core specification clearly states what to do when a PolicyIdReference or > PolicySetIdReference can't be resolved: > If resolving the reference fails, the reference evaluates to “Indeterminate” with status code > urn:oasis:names:tc:xacml:1.0:status:processing-error. This is for the PDP, not the PAP. Thanks, Ray


  • 7.  RE: [xacml] RE: REST API follow up

    Posted 06-01-2012 15:41

    Ray,

    I understand that. My point was that fully resolving policy references is a runtime concern with clearly defined expectations in the core spec, and there's no need to require the PAP to be able to resolve all references during policy upload.

    Regards,
    Craig

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

    ---06/01/2012 02:44:15 AM---Craig, From: Craig R Forster [ mailto:cforster@us.ibm.com ]




    From:
    <remon.sinnema@emc.com>


    To:
    Craig R Forster/Austin/IBM@IBMUS,


    Cc:
    <xacml@lists.oasis-open.org>


    Date:
    06/01/2012 02:44 AM


    Subject:
    RE: [xacml] RE: REST API follow up




    Craig,


    From: Craig R Forster [ mailto:cforster@us.ibm.com ]
    Sent: Friday, June 01, 2012 1:08 AM
    To: Sinnema, Remon
    Cc: Danny.Thorpe@quest.com; xacml@lists.oasis-open.org
    Subject: Re: [xacml] RE: REST API follow up

    > My opinion on this is that the core specification clearly states what to do when a PolicyIdReference or
    > PolicySetIdReference can't be resolved:
    > If resolving the reference fails, the reference evaluates to “Indeterminate” with status code
    > urn:oasis:names:tc:xacml:1.0:status:processing-error.

    This is for the PDP, not the PAP.


    Thanks,
    Ray