[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, There is one more concern which I have about this new matching language. Once the language is there, it is going to be subject to feature creep. In the long term it is going to be a reinvention of XPath. Best regards, Erik Rich.Levinson wrote: > Hi Erik, > > I can either reply with a long detailed email or try something short > and hopefully to the point. I will try the short approach. > > First, I think we can all agree, for example, that a list of files in > a file system can represented equally well by a "dir listing" or a > "dir listing that has been channeled into an xml document format", > such that if one is handed the xml document then they can easily use > the document to tell them how to navigate to any file in the file > system of interest to them. i.e. there is an interchangability between > actual file system navigation and navigation thru an xml document. > > Given that relatively simple point, without going into detail of all > the syntax, brackets, and curly braces vs namespace prefix discussion, > I think the objective I am trying to achieve w the proposal can be > simply stated, namely: > > The objective of the proposal is to provide the ability to system > admins to use the same web access URI techniques they currently > use to control access to html files, for example, and apply those > techniques to control access to nodes in xml documents. > > i.e. the proposal is not intended to enable an admin to say any more > about accessing a node in an xml document than the admin would be able > say about accessing an html file that was addressable w the exact same > path. > > i.e. the first part of the URI, the existing Hier section 2.2, > would be used to identify the specific xml file, > then the second part, the fragment identifier would be able to use > the same slash-component technique to identify the node within the > XML document. > > The admin would write policies that would say something like: > > grant admingroup readprivilege > http://www.example.com/section01/*.xml#/a/b/c/- > > which would allow the admin group to read nodes below the "/a/b/c/" > level in section01 of www.example.com. > So, if someone came in with an http GET on: > > resource-id = http://www.example.com/section01/file01.xml#/a/b/c/d > > the policy above would allow access if they were in the admin group. > > I realize the above policy is not in xacml, however, one could fairly > easily have the admingroup as the subject target, the readprivilege as > the action target, and then write a regular expression to test the > resource-id against the scoped policy. > > Probably no need for constructing resource lists, multi requests could > be simply like: > > resource-id = http://www.example.com/section01/file01.xml#/a/b/c/* > > which would effectively be a query for all the child nodes of /a/b/c > in the doc file01.xml. > > Hopefully, this is enough to make the objectives more clear, and show > why with this relatively limited scope of objective there is no real > need for document content to be provided in the requests, and policies > can be written such that everything can be determined from the query > alone. > > The point is that current web access control products effectively > provide these capabilities, and the idea is to simply provide a > technique to extend this type of capability to the nodes of xml documents. > > Thanks, > Rich > > > Erik Rissanen wrote: >> Hi Rich, >> >> One thing which is missing from this proposal is that there is no >> specification for how the URI selects nodes in the XML document. >> >> Personally I find it difficult to work with expressions like this >> since it is about performing "matching on a matching language" in >> order to get the actual resource. I am concerned that it is easy to >> make a mistake in this dual step matching process, but if others find >> it desirable to work with, I could live with it in the spec. :-) >> >> I understand that it may be desirable in some cases to hide the XML >> content, but that could perhaps be handled better by a construct like >> this: >> >> <Request> >> <Attributes Category="resource"> >> ... >> <ContentReference .....something here..../> >> </Attributes> >> </Request> >> >> With a content reference like this in the core schema, the <Request> >> element could be used as a transport format where the XMl can be >> hidden. And there would be no need to introduce another conceptual >> model for hiding the XML content. When the PDP receives a <Request> >> like this, it would conceptually replace the XML content and behave >> according to the current spec. (Or based on yet another hierarchical >> scheme which we define.) >> >> Best Regards, >> Erik >> >> >> Rich.Levinson wrote: >>> 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 >>> ------------------------------------------------------------------------ >>> >>> >>> --------------------------------------------------------------------- >>> 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 >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]