OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

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]