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