[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
Hi Rich, I agree that your scheme does have the benefit that it can do policy evaluation without access to the resource itself. However, it wouldn't be able to do multiple request generation without access to the resource. Best regards, Erik Rich.Levinson wrote: > Hi Paul, > > Thanks for the comments. I don't significantly disagree with any of > the specific points you mentioned, however, in your point 3, which, if > I read it correctly was addressing my point 1, I don't think your > example directly addresses the point I was making, which is the following: > > * The URI scheme does not require access to either the document or > the database. Authorization is determined prior to accessing any > resources at all. > The XPath scheme requires access to the actual document, or > issuing the query to the database, as you indicated in your > alternative suggestion: "Query book database for candidate records". > The URI scheme would base the decision on the query alone, > before it is executed. The policies would scope based on > policy-specified URI w scope. The request URI would be evaluated > based on whether it fell within the hierarchical scope of the > policy-specified URIs. (all URIs in policy evaluation would be > in the form described in the proposal) > > To me, this is a significant distinction. The reason it is required in > XPath is that the namespaces need to be resolved. With the URI scheme, > the namespaces can be resolved with only the schema of the target > resource, the actual resource does not need to be accessed. i.e. the > risk that is avoided is having an unnecessary access of the resource > prior to determination of authorization. > > Thanks, > Rich > > > 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 >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]