[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Re: XACML's limitations in the access control for XMLdocuments use case - AW: AW: [xacml] CD-1 issue #11: strictness of xpathdefinition
Hi Rich,
Still, it should cover something which the xpath approach does not
cover, or do something better. Could you elaborate what it does beyond
xpath? So far I have only seen examples of how the URI approach can
replicate the xpath approach.
Best regards,
Erik
Rich.Levinson wrote:
> Hi Erik,
>
> The intent of the proposal is not to replace or be better than XPath,
> but to be an "alternative representation" for node identification as
> described in section 2.0 of the profile, which if we included in the
> profile as suggested in section 2.2.1, presumably would then be a
> "recommended alternative representation".
>
> The reason for the suggestion was to address the requirements
> specified in issue 11, which contained a recommended syntax that did
> not incorporate namespaces. By using the Clark notation for the
> namespaces, the syntax in issue 11 can be directly incorporated to the
> URI scheme as described in the proposal.
>
> Once the syntax is in place then the same kinds of regexp-scoped
> Policy's can be written for XML nodes as for file system and URL
> resources.
>
> Assuming the syntax and proposal is correct, it may be a useful
> alternative representation in some situations, particularly where it
> may be an objective to identify all resources w URIs, and/or where the
> mixed XACML/XPATH syntax is a concern wrt Policy specification.
>
> Thanks, Rich
>
>
> Erik Rissanen wrote:
>> Hi Rich,
>>
>> Some of the reasons why an XPath approach could be better are:
>>
>> 1. XPath contains many functions and other capabilities, which might
>> not be as easily available in the URI based approach.
>>
>> 2. The TC would avoid the effort to define the URI approach. We would
>> need to improve the xpath approach instead, but I suspect that the
>> effort is smaller since we can reuse so much from xpath, compared
>> with a wholly new URI based approach.
>>
>> 3. It is likely that an XML resource is already available in XML
>> form, so an xpath implimentation can be applied to it directly, while
>> the URI approach requires a transformation, which could degrade
>> performance.
>>
>> Note that it is not true that the whole XML has to be repeated for
>> each resource since multiple <Attributes> elements are not required
>> with the xpath approach, and with XACML 3.0 it is possible to reuse
>> the same <Content> document for all the multiple queries.
>>
>> Best regards,
>> Erik
>>
>> Rich.Levinson wrote:
>>>
>>> Hi Jan, et al,
>>>
>>> I have had a busy week and not been able to respond until now,
>>> however, looking over all the subsequent emails to the one to which
>>> this is a response (
>>> http://lists.oasis-open.org/archives/xacml/200909/msg00081.html
>>> ), it appears to me that there are still unresolved issues, and from
>>> my perspective, there are some assertions made, with which I
>>> disagree, about AttributeDesignators, which I thought my suggested
>>> URI scheme would address, but apparently it either needs further
>>> explanation or I am missing something that I have not yet
>>> understood. In any event I would very much like to determine whether
>>> these assertions are true or false in order that the TC be of a
>>> single mind when comparing the capabilities of AttributeSelectors
>>> and AttributeDesignators.
>>>
>>> The assertion with which I disagree is that the AttributeDesignators
>>> cannot do what the AttributeSelectors can do because the
>>> AttributeDesignators lose the hierarchical structure. My response is
>>> that if you don't throw away the hierarchical structure when
>>> creating your AttributeDesignators then this perceived problem does
>>> not exist.
>>>
>>> If I am wrong about this, I will accept that, however, I do not
>>> believe that my approach to the AttributeDesignators has been
>>> considered on its merits yet, and I will try to be totally explicit
>>> in this email, and I will show how I think Jan's proposed solution
>>> can be completely done using only AttributeDesignators and regexp
>>> string matching.
>>>
>>> Having been thru some lengthy discussions earlier this year on the
>>> hierarchical profile, I became quite sensitive to the node naming
>>> issue, and one of the results of those earlier discussions was that
>>> if hierarchical URIs are used to name nodes, that these names
>>> contain within them the navigation necessary to locate the node, so
>>> that using these names outside of an XML document does not lose the
>>> structural relationships.
>>>
>>> Using James Clark's universal name syntax ("{namespace}elementname"
>>> http://www.jclark.com/xml/xmlns.htm) combined with a transform to
>>> replace the xml document with a list of name/value pairs (there are
>>> several XML to JSON xslt transformers available free, which I expect
>>> could readily be adapted to produce name/value pairs in the format
>>> below), where each element and attribute is identfied by its full
>>> path expressed as universal element names. For example, assuming the
>>> document you gave as an example had a namespace = "foo":
>>>
>>> <objects xmlns:="foo">
>>> <book>
>>> <title>xxx</title>
>>> <author>Bob</author>
>>> <id>100</id>
>>> <price>30</price>
>>> <book-content>.....</book-content >
>>> <book>
>>> <book>
>>> <title>yyy</title>
>>> <author>Alice</author>
>>> <id>200</id>
>>> <price>80</price>
>>> <book-content >...</book-content >
>>> <book>
>>> </objects>
>>>
>>> The above document would first be transformed to the following set
>>> of name value pairs (ignoring whitespace):
>>> /{foo}objects = ""
>>> /{foo}objects/{foo}book[1] = ""
>>> /{foo}objects/{foo}book[1]/{foo}title = "xxx"
>>> /{foo}objects/{foo}book[1]/{foo}author = "Bob"
>>> /{foo}objects/{foo}book[1]/{foo}id = "100"
>>> /{foo}objects/{foo}book[1]/{foo}price = "30"
>>> /{foo}objects/{foo}book[1]/{foo}content = "..."
>>> /{foo}objects/{foo}book[2] = ""
>>> /{foo}objects/{foo}book[2]/{foo}title = "yyy"
>>> /{foo}objects/{foo}book[2]/{foo}author = "Alice"
>>> /{foo}objects/{foo}book[2]/{foo}id = "200"
>>> /{foo}objects/{foo}book[2]/{foo}price = "80"
>>> /{foo}objects/{foo}book[2]/{foo}content = "..."
>>>
>>> The next step is to define resources, which for this use case would
>>> be done based on multiple resource profile, where we would have 2
>>> resources, using Erik's shorthand:
>>> <Resource>resource-id=/{foo}objects/{foo}book[1]</Resource>
>>> <Resource>resource-id=/{foo}objects/{foo}book[2]</Resource>
>>>
>>> The next step is to create xacml attributes for these resources
>>> using the full universal names as AttributeIds (again w some
>>> shorthand), resulting in the following 2 requests:
>>> (Note: since AttributeId requires anyURI datatype, the following
>>> percent-encoding must be applied to the AttributeId values:
>>>
>>> * { -> %7B
>>> * } -> %7D
>>> * [ -> %5B
>>> * ] -> %5D )
>>>
>>>
>>> <Request>
>>> <Subject>subject-id="Bob"</Subject>
>>> <Resource>
>>> <Attribute>AttributeId="resource-id"
>>> value="/{foo}objects/{foo}book[1]"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dtitle"
>>> value = "xxx"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dauthor"
>>> value = "Bob"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Did"
>>> value = "100"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dprice"
>>> value = "30"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dcontent"
>>> value = "..."</Attribute>
>>> </Resource>
>>> </Request>
>>>
>>> <Request>
>>> <Subject>subject-id="Bob"</Subject>
>>> <Resource>
>>> <Attribute>AttributeId="resource-id"
>>> value="/{foo}objects/{foo}book[2]"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dtitle"
>>> value = "yyy"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dauthor"
>>> value = "Alice"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Did"
>>> value = "200"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dprice"
>>> value = "80"</Attribute>
>>> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dcontent"
>>> value = "..."</Attribute>
>>> </Resource>
>>> </Request>
>>>
>>> All the above processing to create the requests is done in the
>>> ContextHandler, then the requests are submitted one at a time to the
>>> PDP.
>>> Now the rule that gets applied to each of these requests is the
>>> following:
>>>
>>> <Rule effect=Deny>
>>> Target:
>>> reg-exp-string-match(resource-id, /{foo}objects/{foo}book\[\d+\]
>>> Condition:
>>> AttributeDesignator(AttributeId =
>>> function:string-concatenate(resource-id, /%7Bfoo%7Dprice) > 50 and
>>> AttributeDesignator(AttributeId =
>>> function:string-concatenate(resource-id, /%7Bfoo%7Dauthor) =
>>> AttributeDesignator(subject-id)
>>> </Rule>
>>>
>>> Unless I am mistaken, all the logic and structure is retained and it
>>> has been done purely w AttributeDesignators and regexp.
>>>
>>> Assuming the above is correct, then the points I made about the
>>> advantages over XPath (for an enterprise looking to use only URIs to
>>> identify attributes):
>>>
>>> 1. The XML document does not need to be passed in with the request.
>>> There is no node collection, only string operations.
>>> 2. For very large XML documents, say a catalog of 10,000 books, each
>>> book is processed individually independent of the other books, as
>>> compared to the XPath case, where one might expect the whole
>>> document has to get parsed for each of the 10,000 individual
>>> requests.
>>> 3. There is no paradigm shifting, or what I believe was referred to
>>> in the discussion as "shifting semantics between XPath and XACML
>>> in terms of representing the policies.
>>>
>>> Again, assuming the above is correct, I am not assuming this will be
>>> desirable for everyone, however there may very well be organizations
>>> for whom the advantages of this approach are decisive.
>>>
>>> A couple other points are that
>>>
>>> * the "unsightliness" of the AttributeIds and the
>>> AttributeDesignators can be "covered" up by policy tools that
>>> facilitate defining policies based on XML Schemas, and can keep
>>> all the encoding details transparent to the policy designers.
>>> * the issue about basing policies on the structure of XML documents
>>> is a legitimate concern, however, if structure of documents
>>> change, then a legitimate case could probably made that the
>>> namespace associated with that structure should also change, which
>>> would mean the policy tools would need to be able to facilitate
>>> upgrading of policies to new namespaces based on new revs of the
>>> schemas.
>>>
>>> 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]