[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Revised proposal for issue #11, using XPath/URI pathexpressions
Hi Rich, Thanks for the clarification. I thought you said that the same attribute values (and thus the same request) could be used directly for both schemes without modification. But what you actually say is that the same fragment can be reused as a piece to implement either scheme, though separately. I would agree with that. Best regards, Erik Rich.Levinson wrote: > Hi Erik, > > Let me try to explain with a very simple example just to show the flow. > > * Say we have an xml document foo.xml w content: > <A><B>BValue</B></A> > located at <uri> = http://ex.com/foo.xml. > * For simplicity, assume the caller knows nothing of the files or > xml, but that the pep somehow knows the user needs to access the > content of /A/B in order to be granted access. > * Also to simplify discussion, assume there is another clause in the > proposal that says: > <fragment> = "/" <fragment-id> > so the discussion following without losing generality will focus > on <fragment-id>, which consists of everything on line 254 of > proposal except for the leading slash. > * According to the proposal, the <fragment-id> that would be created > to access /A/B, would be: > <fragment-id> = > *:A[namespace-uri()=""][1]/*:B[namespace-uri()=""][1] > which, because of the empty namespace-uri value, would reduce to: > <fragment-id> = A[1]/B[1] > * Now, using core Example 2: request context section 4.2.2 and rule > 2, section 4.2.4.2 as a guide, for the request context, we could > include an Attribute as follows: > <Attribute AttributeId="...resource:resource-id"> > <AttributeValue > XPathCategory="...attribute-category:resource" > DataType="...data-type:xpathExpresssion" > >A[1]/B[1]</AttributeValue></Attribute> > where we just insert <fragment-id> as the AttributeValue. > * Similarly, the policy, like 4.2.4.2 lines g64-g75 would say: > <Match MatchId="...function:xpath-node-match"> > <AttributeValue > DataType="...data-type:xpathExpression" > XPathCategory="...attribute-category:resource" > >A</AttributeValue> > <AttributeDesignator MustBePresent="false" > Category="...attribute-category:resource" > AttributeId="...resource:resource-id" > DataType="...data-type:xpathExpression"> > </Match> > * By comparison, with the URI method, one would submit a > resource-id of: > <uri>#/<fragment-id> > and use regular expression matching as we've discussed. > > The point is that the same automatically constructed string, > <fragment-id> could be used by both methods. And, the reason I am > suggesting it, is that for the multiple resource profile, for both the > xml and non-xml use cases there is a need for constructing > resource-id's, which are capable of individually addressing every node > in an XML document. It seems to me that this technique, which I > believe enables the URI approach to encompass both non-XML and XML > resources, can be used with the XPath-oriented method as well. > > Thanks, > Rich > > Erik Rissanen wrote: >> Hi Rich, >> >> No, I still don't understand how the identifiers could be used as >> xpaths in policies. >> >> I can understand the regexp case. For instance, assume that the >> request contains >> >> <Attributes Category="resource"> >> <Attribute AttributeId="resource-id"> >> <AttributeValue >> Datatype="anyURI">http://example.com/foo#*:bar[namespace-uri='example.com/ns1']</AttributeValue> >> >> ... >> </Attribute> >> ... >> </Attributes> >> >> then one could do something like this in a policy: >> >> <Match MatchId="urn:....:anyURI-regexp-match"> >> <AttributeValue Datatype="string">...some regexp >> here...</AttributeValue> >> <AttributeDesignator AttributeId="resource-id" Datatype="anyURI"/> >> </Match> >> >> But how would you use the resource-id as an xpath expression? Where >> would you put it in the policy and using what construct? >> >> Best regards, >> Erik >> >> Rich.Levinson wrote: >>> Hi Erik, >>> >>> You were right about the syntax, there needs to be a leading "*" in >>> order to collect "all" the child nodes and then discriminate based >>> on local-name() and namespace-uri(). However, I did find the >>> "*:<local-name-literal> works as well, so I modified the spec >>> (attached) to include a leading "*:" (star-colon) before the >>> local-name-literals. I also added a couple of notes to indicate >>> that, as well as pointing out that the strings >>> >>> * /*:abc[namespace-uri()=""] >>> * /abc >>> >>> are equivalent, so that for the no-namespace use cases, there is no >>> need for the prefix and predicate. >>> >>> On the issue of how xacml treats the identifier, I finessed that a >>> bit as follows: it is the <fragment> item that is serving as the >>> identifier within the XML document itself. So, as specified, it >>> should work as an xpathExpression, possibly without the leading "/", >>> in an AttributeSelector. The proposed specification says that the >>> expressions that conform to the proposed <fragment> layout only need >>> to be percent-encoded when put within a URI. So, for example, if one >>> wanted to use it as the AttributeValue for a resource-id Attribute, >>> there is no technical reason why it needs to be percent-encoded. >>> >>> Regarding issue 11, the problem was to pin down a consistent syntax >>> so that regular expression matching rules could be specified. The >>> original proposal I submitted addressed this issue by providing a >>> non-xpath syntax in the hierarchical URI scheme, which provided an >>> "alternative" representation for identifying the nodes in an XML >>> document. >>> >>> Further analysis of the problem, and especially Paul's raising the >>> issue of resource-id's caused me to consider the present proposal, >>> which I consider superior to the original proposal because it serves >>> to layout a method by which identifiers can be automatically >>> produced that can be used by both the XPath representation and the >>> URI representation, which potentially provides a clean break between >>> the naming of the node and the accessing of the node. The particular >>> XPath syntax proposed appears to enable the separation of these two >>> operations so that the literal XPath expressions can be used either >>> as literal identifiers or operational language statements, that >>> "identify" the node in the former case and "access" the node in the >>> latter case.. >>> >>> Hopefully, the above comments address the concerns you raised. >>> >>> Thanks, >>> Rich >>> >>> >>> >>> Erik Rissanen wrote: >>>> Rich, >>>> >>>> You say that the identifier serves as"an executable expression that >>>> can be applied to an XML document". That is true from a >>>> threoretical point of view, but there are currently no XACML >>>> functions which can operate on an URI like this. The URI needs to >>>> be resolved and then the path needs to be extracted before it can >>>> be applied as an XPath expressions. So it is a fundamentally new >>>> scheme, not a modification to the XPath scheme which started issue >>>> #11. >>>> >>>> BTW, did you check the XPath syntax? If I recall correctly from the >>>> past, foo[namespace-uri="bar"] does not work. I think I had to do >>>> *[localname='foo'][namespace-uri='bar']. I could be wrong though... >>>> >>>> Best regards, >>>> Erik >>>> >>>> Rich.Levinson wrote: >>>>> To TC: >>>>> >>>>> As described in previous email: >>>>> http://lists.oasis-open.org/archives/xacml/200911/msg00042.html >>>>> I have revised the original proposal submitted for issue 11. >>>>> >>>>> This proposal is intended to address the same problems as the >>>>> previous proposal, and it also provides a format which can >>>>> potentially be used to address the resource-id naming issue raised >>>>> by Paul Tyson: >>>>> http://lists.oasis-open.org/archives/xacml/200911/msg00032.html >>>>> >>>>> A summary of expected benefits from this proposal includes the >>>>> following: >>>>> >>>>> * The proposal provides an automatic naming method for any >>>>> node in >>>>> an XML document, in the form of an XPath path expression, that >>>>> may also be used to retrieve the actual node identified. >>>>> * The proposal shows how to map this expression into standard URI >>>>> format by percent encoding each XPath step component that >>>>> follows a URI fragment slash "/". >>>>> * An XPath step in the proposal is represented by the >>>>> concatenation of 3 strings as a local-name plus two optional >>>>> predicates, each of which is immediately determinable when in >>>>> the XPath context of the document using standard XPath >>>>> functions: local-name(), namespace-uri(), and position() and >>>>> the >>>>> full set of steps in the expression can be used to obtain the >>>>> single node addressed from any XPath context because the >>>>> path is >>>>> absolute. >>>>> * The unencoded XPath path expression can be used as the identity >>>>> of a node in an XML document as described in section 2.1 of the >>>>> hierarchical profile. >>>>> * The unencoded XPath expression can be used as the >>>>> resource-id as >>>>> described in section 2.2.3 of the Multiple Resource Profile. >>>>> * The XPath path expression can be used with or without the >>>>> associated XML document. i.e. the expression serves as BOTH an >>>>> executable expression that can be applied to an XML document >>>>> AND >>>>> a literal identifier that can be used by regular expression >>>>> matching type operations. >>>>> * Percent-encoding of the XPath path expression is only required >>>>> when the expression is used as an actual URI, such as when >>>>> extending the URI mechanism into XML documents to identify >>>>> entities within the document, or when used as an identifier >>>>> that >>>>> requires URI syntax such as an XML AttributeId attribute. >>>>> * In general, because the XPath path expression can operate as a >>>>> literal identifier, it enables policies to be written against >>>>> resources within XML documents which enable policy evaluation >>>>> before the document is accessed. >>>>> >>>>> I will try to prepare a slide presentation prior to the F2F. In >>>>> the meantime, hopefully, the information is intended to be >>>>> self-explanatory. >>>>> >>>>> 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]