OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  Hierarchical Profile and the URI

    Posted 03-10-2009 01:05
    In addition to previously discussed issues, I would like to fix the sections in the hierarchical profile on using URIs.
    
    In section 2.2 the profile says:
    
    ----
    The identity of a node in a hierarchical resource that is not represented as an XML document instance SHALL be represented as a URI that conforms to [RFC2396]. Such URIs are of the following form.
    	


  • 2.  Re: [xacml] Hierarchical Profile and the URI

    Posted 03-10-2009 07:31
    Thanks Hal for the clarifications.
    
    For the URI based scheme which Rich is proposing, we would require that 
    the data type is a URI. It's an alternative form of requests/policies 
    for hierarchical resources, which is independent of and not used in 
    combination with the ancestor scheme. (Or at least that I was I think. 
    Rich, please correct me if I am mistaken.)
    
    I'm not sure what to do with the actual form of the URI. Should we 
    mandate a subset of the URI space? Or do we leave it as something to be 
    agreed between the PEP and PDP/Policies?
    
    Best regards,
    Erik
    
    Hal Lockhart wrote:
    > In addition to previously discussed issues, I would like to fix the sections in the hierarchical profile on using URIs.
    >
    > In section 2.2 the profile says:
    >
    > ----
    > The identity of a node in a hierarchical resource that is not represented as an XML document instance SHALL be represented as a URI that conforms to [RFC2396]. Such URIs are of the following form.
    > 	


  • 3.  Re: [xacml] Hierarchical Profile and the URI

    Posted 03-10-2009 13:28
    
    
      
    
    
    Hi Erik and Hal,

    Erik is correct. The scheme in 3.2.2.1 of the proposed v5-02 is based on the assumption that URIs are in the form prescribed in section 2.2.

    As to accuracy of the "form" in section 2.2, the only real problem I see is that the ":" should be fixed to be "://". I believe this was an oversight in the original.

    As to the inclusion of the "/" after the "<authority>", this is because the <authority> in the notes following is assumed to be always present, which means according to RFC 2396 that a "/" will, at minimum follow.

    The "<path>" is then prescribed to be <root name> [ "/" <node name> ] * , which is a perfectly legal URI.

    As to the intention of this section being simply a faulty summary of the RFC 2396 spec vs a "prescription" recommended URI, I would cite the original email and spec where this data appeared:
    http://lists.oasis-open.org/archives/xacml/200405/msg00104.html

    which says:

    "The revision has the following significant changes:

    1) Proposes a standard URI representation for hierarchical resources that are not XML documents. This representation allows use of the anyURI-equal and anyURI-match functions where the path to a requested node is important. This representation may be overridden by a resource-specific Profile. ..."
    This appears to fairly unambiguously state that it is a prescription specially defined to ensure that it would work with the anyURI functions.

    Furthermore, the whole section in the actual text of that revision (attached to the email ref) was prefaced by this sentence:
    "Unless otherwise specified by a resource-specific Profile, the identity of a node in a resource that is not an XML document SHALL be in the form specified the remainder of this Section."
    This sentence appears to have been dropped in some rearrangement of the next version:
    http://lists.oasis-open.org/archives/xacml/200406/msg00008.html
    http://lists.oasis-open.org/archives/xacml/200406/msg00009.html

    where the first email describes the release, which was only breaking up the previous version into the multi and hier profiles, and specifically says that it "contains the same hierarchical resources content" as the previous version. Point being any info conveyed in above sentence was not intentionally dropped as indication of change of purpose.

    Bottom line on URI section 2.2, is that I think it is fine except for above typo of "://" and there might be some slight grammatical corrections needed.

    Any other prescription for URI forms or other node identity representations that people might want, I suggest be put in another section.

    One final note is that it is interesting to follow the evolution of what was to become the final 3.2 algorithms for ancestor selection in these early drafts. It is pretty clear that the original hierarchies were regarded as a forest and there was no explicit intention to transform these into a DAG, which is the unfortunate result of the subsequent changes that were made to these algorithms, which in seemingly innocent identification of ancestors to be collected apparently inadvertently created the implied condition that the collection became transformed to a DAG.

    Again, I do not recommend removing the DAG transformation and keep it in the v5-02 section 3.2.1, however, we do need to include the option for the forest representation, which is covered in v5-02 section 3.2.2. Finally, the 2.2 URI section is picked up as the concrete forest "implmentation" in section 3.2.2.1.

        Thanks,
        Rich



    Erik Rissanen wrote:
    49B6170A.50204@axiomatics.com" type="cite">Thanks Hal for the clarifications.

    For the URI based scheme which Rich is proposing, we would require that the data type is a URI. It's an alternative form of requests/policies for hierarchical resources, which is independent of and not used in combination with the ancestor scheme. (Or at least that I was I think. Rich, please correct me if I am mistaken.)

    I'm not sure what to do with the actual form of the URI. Should we mandate a subset of the URI space? Or do we leave it as something to be agreed between the PEP and PDP/Policies?

    Best regards,
    Erik

    Hal Lockhart wrote:
    In addition to previously discussed issues, I would like to fix the sections in the hierarchical profile on using URIs.

    In section 2.2 the profile says:

    ----
    The identity of a node in a hierarchical resource that is not represented as an XML document instance SHALL be represented as a URI that conforms to [RFC2396]. Such URIs are of the following form.
        <scheme> ":" <authority> "/" <pathname> ----

    This is not true and it is not what RFC 2396 says. In section 3, it says:

    ---
    The URI syntax is dependent upon the scheme.  In general, absolute
       URI are written as follows:

          <scheme>:<scheme-specific-part>

       An absolute URI contains the name of the scheme being used (<scheme>)
       followed by a colon (":") and then a string (the <scheme-specific-
       part>) whose interpretation depends on the scheme.

       The URI syntax does not require that the scheme-specific-part have
       any general structure or set of semantics which is common among all
       URI.  However, a subset of URI do share a common syntax for
       representing hierarchical relationships within the namespace.  This
       "generic URI" syntax consists of a sequence of four main components:

          <scheme>://<authority><path>?<query>

       each of which, except <scheme>, may be absent from a particular URI.
       For example, some URI schemes do not allow an <authority> component,
       and others do not use a <query> component.
    ----

    Some URI schemes use a hierarchical path component with segments separated by "/" and others do not. This is not mere nitpicking as the XML Schema AnyURI type is defined as containing "a URI as defined by RFC 2396. This means a valid type checked element of type AnyURI can contain something like email:john@example.com or http://www.example.com/main/index.html.

    It seems to me that we should recommend as a matter of best practice that policies first check the scheme name using the uri-starts-with function before using any regex functions to pick the hierarchical portion apart.

    This brings us the question of what type of URI to allow or permit to be used to represent a hierarchical resource on the non-XML type. Obviously since we decided to allow any data type, we can no longer require that a URI be used at all. However, I suggest we follow the existing profile and say that if a URI is used, then if the resource already is named using a registered scheme OF THE HIERARCHICAL TYPE, then that should be used, otherwise a "file" scheme URI should be constructed as described in the current (2.0) profile.

    Hal


    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
     


    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


  • 4.  RE: [xacml] Hierarchical Profile and the URI

    Posted 03-10-2009 13:54
    
    
    
    
    


  • 5.  Re: [xacml] Hierarchical Profile and the URI

    Posted 03-10-2009 14:02
    Hi Hal,
    
    I think I have used the term "URI scheme" in a sloppy manner, and I can 
    see that I have confused you. :-)
    
    One meaning of "URI scheme" is the manner in which we restrict the 
    allowed forms of the URI, which I think you are thinking about here.
    
    I have used "URI scheme"  in the meaning of a third way to do 
    hierarchical access control. The first is the 2.0 profile "nodes in XML 
    documents". The second is the 2.0 profile "nodes in resources that are 
    not XML documents".
    
    The third variant, which I have called "the URI scheme", is another, 
    entirely different way of doing hierarchical access control which Rich 
    has proposed: to use regular expression matching on a URI. In this case 
    the ancestor are not listed as separate attributes in the request context.
    
    For clarity, I think we should have a name for the third method. What 
    about "nodes in resources which are hierarchical URIs". Maybe "URI 
    matching" for short? Anyone have a better name?
    
    Best regards,
    Erik
    
    Hal Lockhart wrote:
    >
    > My reading of the 2.0 Profile is that you MUST use a file: scheme URI 
    > (or other hierarchical URI scheme, modulo some sloppy wording) to name 
    > the Parents and Ancestors as well as the Resource and that Parents and 
    > Ancestors MUST be provided in order to comply with the Profile.
    >
    >  
    >
    > Out of a desire to retain as much compatibility with 2.0 as possible, 
    > I was proposing only the parts needed to meet various requirements and 
    > concerns be changed. To me the minimum change seems to be to keep the 
    > URI scheme largely the same and allow the possibility of non-URI 
    > identifiers.
    >
    >  
    >
    > Hal
    >
    >  
    >
    >  
    >
    > ------------------------------------------------------------------------
    >
    > *From:* Rich.Levinson [mailto:rich.levinson@oracle.com]
    > *Sent:* Tuesday, March 10, 2009 9:27 AM
    > *To:* Erik Rissanen
    > *Cc:* hal.lockhart@oracle.com; xacml@lists.oasis-open.org
    > *Subject:* Re: [xacml] Hierarchical Profile and the URI
    >
    >  
    >
    > Hi Erik and Hal,
    >
    > Erik is correct. The scheme in 3.2.2.1 of the proposed v5-02 is based 
    > on the assumption that URIs are in the form prescribed in section 2.2.
    >
    > As to accuracy of the "form" in section 2.2, the only real problem I 
    > see is that the ":" should be fixed to be "://". I believe this was an 
    > oversight in the original.
    >
    > As to the inclusion of the "/" after the "


  • 6.  RE: [xacml] Hierarchical Profile and the URI

    Posted 03-10-2009 14:32
    I did understand what you meant. What I was trying to get at is I believe the 2.0 Profile requires hierarchical URIs and the ancestor stuff. In this case, the hierarchical URIs can be operated on by any of the URI type functions.
    
    As I said in the first msg after the call, the only drawback I see to this is that the ancestor information and the URI form might be inconsistent with each other. As I also said, there are lots of other ways that the Request Context can contain inconsistent information, which we do not prohibit, so this does not seem like a serious issue.
    
    If we split these two approaches, rather than leaving them merged, then we will only avoid inconsistencies by requiring that when Ancestor information is provided, it is prohibited to name the resource and its ancestors using a hierarchical URI. This seems too extreme. It seems to me to be desirable to let users name their resources in the most natural way for their environment.
    
    I don't feel that strongly about this, so if the TC wants to change the Profile to say that in the non-XML case you can either provide a bunch of hierarchical names OR provide a bunch of non-hierarchically named ancestors, them I will go along with it.
    
    Hal
    
    > 


  • 7.  Re: [xacml] Hierarchical Profile and the URI

    Posted 03-10-2009 16:30
    Hi Hal,
    
    I think the point with the "URI matching" method is to gain a 
    performance and implementation simplicity advantage by not having to 
    provide the ancestor attributes. If we would require the ancestor 
    attributes as well for the URI matching method, then the URI matching 
    method becomes somewhat meaningless.
    
    Best regards,
    Erik
    
    Hal Lockhart wrote:
    > I did understand what you meant. What I was trying to get at is I believe the 2.0 Profile requires hierarchical URIs and the ancestor stuff. In this case, the hierarchical URIs can be operated on by any of the URI type functions.
    >
    > As I said in the first msg after the call, the only drawback I see to this is that the ancestor information and the URI form might be inconsistent with each other. As I also said, there are lots of other ways that the Request Context can contain inconsistent information, which we do not prohibit, so this does not seem like a serious issue.
    >
    > If we split these two approaches, rather than leaving them merged, then we will only avoid inconsistencies by requiring that when Ancestor information is provided, it is prohibited to name the resource and its ancestors using a hierarchical URI. This seems too extreme. It seems to me to be desirable to let users name their resources in the most natural way for their environment.
    >
    > I don't feel that strongly about this, so if the TC wants to change the Profile to say that in the non-XML case you can either provide a bunch of hierarchical names OR provide a bunch of non-hierarchically named ancestors, them I will go along with it.
    >
    > Hal
    >
    >   
    >> 


  • 8.  RE: [xacml] Hierarchical Profile and the URI

    Posted 03-10-2009 16:49
    Well as I said, I don't feel too strongly about this, but the 2.0 profile requires you do both, so apparently some folks thought that there might be a need to do not merely matching, but also parsing of the URI even when the ancestor attributes have been provided.
    
    Hal
    
    > 


  • 9.  Re: [xacml] Hierarchical Profile and the URI

    Posted 03-10-2009 20:45
    >
    > As I said in the first msg after the call, the only drawback I see  
    > to this is that the ancestor information and the URI form might be  
    > inconsistent with each other. As I also said, there are lots of  
    > other ways that the Request Context can contain inconsistent  
    > information, which we do not prohibit, so this does not seem like a  
    > serious issue.
    
    > If we split these two approaches, rather than leaving them merged,  
    > then we will only avoid inconsistencies by requiring that when  
    > Ancestor information is provided, it is prohibited to name the  
    > resource and its ancestors using a hierarchical URI. This seems too  
    > extreme. It seems to me to be desirable to let users name their  
    > resources in the most natural way for their environment.
    >
    
    
    A common use case would be web application resources integrated in  
    some mash up application.  More often then not their logical  
    relationship that is relevant for access control are not reflected in  
    there location names.   I do not think it will be wise to make people  
    to use any particular naming scheme just for compatibility with XACML.
    
    
    > I don't feel that strongly about this, so if the TC wants to change  
    > the Profile to say that in the non-XML case you can either provide  
    > a bunch of hierarchical names OR provide a bunch of non- 
    > hierarchically named ancestors, them I will go along with it.
    >
    
    I think that the ancestors profile should be very clear about the  
    fact that it is completely independent of a naming scheme for the  
    resources.
    
    Daniel;