Re: [xacml] Proposal to address issue 11, and thoughts on whetherit is advisable or not to separate out sections of hier, mult to a new profile

[Erik Rissanen <erik@axiomatics.com>]

I agree with Paul on that regexp is a poor choice for working with XML 
content. But for the sake of moving forward, I could live with an 
optional section in the spec and let the market decide whether it is 
worth using.

Best regards,
Erik


Tyson, Paul H wrote:
> I still can find no compelling reason to introduce this into the 
> standard.  Any enterprise could certainly adopt this system of 
> resource identification without violating the XACML specification.  I 
> cannot see any advantage in doing this, but I believe Rich when he 
> says there may be highly constrained situations that force one to this 
> type of solution.  That is not a good enough reason to put it in the 
> standard, though.
>  
> To address some specific points:
>  
> 1. XPath performance overhead.  I don't know what others have 
> experienced, but I have used saxon xslt engine for years, and simply 
> cannot slow it down no matter how complex my xpath expressions are, or 
> how large the input documents are.  I don't know what xpath engines 
> are commonly used in XACML implementations, but poor performance is 
> not an inherent feature of xpath processing.  In the case of multiple 
> authorization decisions on a single document, it would be a very naive 
> implementation that actually re-parsed the document for every decision.
>  
> 2. Paradigm shifting: Attribute(Designator|Selector), xpath vs. 
> regex.  Really, who *likes* regex? ;-) XACML is an XML application, 
> therefore the first and favored approach should be xpath.  It's nice 
> to be able to use regex when necessary, but I have never seen a case 
> where it is the best first choice in XML processing (except for 
> datatyping and value checking, but those areas are outside the domain 
> of xpath).  A developer who knows regex better than xpath would want 
> to use regex first, but xpath is a much more natural fit with XML.
>  
> 3. Not wanting to expose entire XML document to PDP.  If this is a 
> hard constraint, there are other architectural alternatives.  Take the 
> book catalog use case.  For my money, I would do something like this 
> before using the alternative URI representation:
>     a. Query book database for candidate records
>     b. Send multi-decision request with attributes like ((user=Jones), 
> (type=book, author=Jones, price=50), 
> (type=book,author=Smith,price=30), ...)
>     c. Receive results
>     d. Form XML for delivery to user, based on results.
>  
> This model would work for all cases where the XML is manufactured from 
> database or other backend sources.  Just move the authorization step 
> ahead of the XML creation.
>  
> The book use case does not actually depend on any hierarchical 
> relations for the decision, so it is not the best example.
>  
> Regards,
> --Paul
>
>     ------------------------------------------------------------------------
>     *From:* Rich.Levinson [mailto:rich.levinson@oracle.com]
>     *Sent:* Monday, October 12, 2009 22:02
>     *To:* xacml
>     *Subject:* [xacml] Proposal to address issue 11, and thoughts on
>     whether it is advisable or not to separate out sections of hier,
>     mult to a new profile
>
>     Based on Oct 8 TC meeting, proposals were solicited to address
>     both issue 11, and the broader issue of whether or not we should
>     consider separating out the XML document parts of Hier, Mult to
>     another profile.
>
>     The attached document represents a proposed addition to Hier
>     profile to address issue 11 (it is the same as attachment to
>     http://lists.oasis-open.org/archives/xacml/200909/msg00076.html,
>     except w highlight changes turned off to make Hier sections 2.2,
>     2.2.1 easier to read). (It is also included as attachment to
>     emphasize it is a proposal, as opposed to a draft of an agreed
>     change, which would be rev'd in the repository)
>
>     The following comments state why I think the proposed addition to
>     Hier is needed (#1, #2) and why I think the hierarchical
>     properties of XML documents should remain in the Hier/Mult
>     profiles (#3), and that if other profiles are developed for XML
>     docs then those profiles should refer to Hier/Mult for their
>     hierarchical access properties.
>
>        1. The proposed addition to Hier is needed because it
>           represents functionality that is currently missing from the
>           Hier profile that enables identifying resources within an
>           XML document without having to provide the XML document itself.
>
>               * The problem introduced by requiring the presence of
>                 the XML document is that, for example, it requires
>                 actually accessing and exposing the protected
>                 resources in order to determine if access is allowed
>                 to those same resources. While this may be an
>                 acceptable increase in risk of exposure in some
>                 application environments, it may not be acceptable in
>                 others where very sensitive data is involved, and an
>                 alternative should be provided for those cases.
>
>               * For more specific example, XML-frontended datastores
>                 contain resources in relational or other legacy
>                 storage mechanisms and primarily use XML as vehicle
>                 for containing and carrying those resources. Requiring
>                 construction of XML documents containing those
>                 resources, which could potentially contain very
>                 sensitive data, in order to construct a request to
>                 determine whether access to those resources is allowed
>                 should not be required if alternative mechanisms which
>                 do not require this exposure are readily available.
>
>        2. The proposed addition is also needed to provide a unique
>           uniform naming mechanism and policy reference mechanism for
>           all hierarchical resources whether they are contained in an
>           XML document structure or some other hierarchical structure.
>           i.e. XML documents have an inherently simple hierarchical
>           structure that has an implicit resolved name structure in
>           the underlying XPath data model that should be able to be
>           used for resource identification and policy definition
>           despite the fact that the XPath language, itself, does not
>           expose this capability of the underlying reference model.
>
>               * The attached proposal uses a commonly used mechanism
>                 (Clark notation: curly braces around resolved
>                 namespace prefix) that addresses the omission from the
>                 XPath language of the ability to enable single string
>                 display representation of explicit full hierarchical
>                 path to each node. This path is also percent-encoded
>                 where required in order that it can be used as a URI
>                 fragment as described in section 2.2.1 of attachment,
>                 which seamlessly augments the existing Hier URI scheme
>                 in section 2.2.
>
>        3. It is recommended to leave the XML document sections in
>           Hier/Mult for the following basic reason: The introduction
>           to the Hier profile (section 1, lines 41-54) makes it clear
>           that XML documents are regarded as generally only one
>           possible "representation" of the actual target hierarchical
>           resources. Therefore there seems to be little to be gained
>           by separating out one representation of the general
>           hierarchical resources covered by the profile into a
>           separate profile. What would seem to make more sense is that
>           a more general XML/WebServices profile could reference the
>           Hier profile when necessary for matters concerning the
>           "hierarchical" access control aspects of the  more general
>           XML/WebServices problem space addressed by that new profile.
>
>     Additional context for this proposal has already been discussed in
>     tc emails and will not be repeated here, but may be found in the
>     following references to those emails:
>
>         * The change represents missing functionality as initially
>           outlined here:
>           http://lists.oasis-open.org/archives/xacml/200909/msg00075.html
>
>         * The specific change that was outlined in above ref, was
>           explicitly contained in the attachment to this email:
>           http://lists.oasis-open.org/archives/xacml/200909/msg00076.html
>
>         * Trade-offs between the URI and XPath approach, including the
>           fact that URI does not require the presence of the actual
>           XML document,  were considered in this email:
>           http://lists.oasis-open.org/archives/xacml/200909/msg00079.html
>
>         * A detailed walkthru of one possible use case, selected to
>           show direct comparison between the XPath and URI approaches
>           was  contained in this email:
>           http://lists.oasis-open.org/archives/xacml/200909/msg00099.html
>
>         * The following email discusses in more detail the relation of
>           the URI-reference scheme naming and the implicit Mult scoping:
>           http://lists.oasis-open.org/archives/xacml/200910/msg00007.html
>
>     Comments and suggestions welcome.
>
>         Thanks,
>         Rich
>