[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] Issue: SubjectsType and ResourcesType definitions
I have had the same concern with Anne. I think we need the semantics of
equality based on our real requirements. Considering the equality, I think
that it is difficult to ignore the data model and the equality semantics of
the XPath 1.0. First, I characterize our requirements for the equality
operator:
1) An argument of the equality operator is either a location path to some
node to the XML document, a constant value, or some function call.
2) Evaluation result of the above location path is either an empty set, a
node, or multiple nodes, where node itself may include a structure.
3) Thus equality must support comparison among empty set, a node, or
multiple nodes.
Since XPath 1.0 is a recommendation of the path language for XML, we should
use XPath 1.0 as a location path language (I don't mean a full set of the
spec but need only a subset). In the XPath 1.0, it supports four data
types: node-set, boolean, number, and string. It also defines the equality
based on those data types and potentially multiple nodes.
The problems I found in XPath 1.0 is the following:
A) When multiple nodes are returned, the equality is determined by
existential semantics i.e. if there is one node found in the multiple nodes
that matches the other arguments, then the equality is satisfied.
B) When a node is structured in depth, the equality is determined by
assuming some mapping to a string-value that may not satisfy the structure
and data equivalence between two hierarchies.
C) There is no difference between integer and floating point number in
their data model
For A, based on Anne's suggestion, we need some "ALL match" equality in
addition to "SOME match" (existential) equality. We have to invent some
scheme to support this because even in XPath 2.0, there seems no function
that supports this comparison.
For B, in XPath 2.0, there is a function called "deep-equal" and
"sequence-deep-equal" that supports the comparison with structured node. We
can borrow this semantics to support structural equality.
For C, we cannot distinguish two numerical types from the output of the
XPath processor. In XPath 2.0, they supports integer (12), decimal (12.5),
and double (125E2). However, it is not impossible to support those notation
in XPath 1.0.
My suggestion is the following:
a) We should support both the semantics "ALL match" equality and "SOME
match" equality. For SOME match, I think the operator of the "general
comparison" defined in XQuery can be used. For "ALL match", we have to
define by ourselves.
b) We should borrow the semantics of "deep-equal" and "sequence-deep-equal"
in our spec after considering differences between XPath 1.0 data model and
XPath 2.0 data model.
c) If we need to distinguish integer from floating point, there is a way to
distinguish even in XPath data model, provided the XPath implementation
supports API that returns the original string. Another idea is to give up
sufficient numerical data type support in XACML 1.0.
d) We support another matching function based on regular expression besides
the above equality feature.
Finally, my personal opinion is that XACML 1.0 should be basically built
upon the XPath 1.0 data model and semantics except for a couple of
important features. When XPath 2.0 becomes a recommendation, then XACML 2.0
supports full functions of XPath 2.0 data model and functions. This implies
that we don't support in XACML 1.0 the following features:
- Datetime related functions and data types as a mandatory functions and
data types. Each implementation may support them locally.
- Only floating point is supported as a numerical data type.
Michiharu
IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
Anne Anderson
<Anne.Anderson@Su To: XACML TC <xacml@lists.oasis-open.org>
n.com> cc:
Subject: [xacml] Issue: SubjectsType and ResourcesType definitions
2002/07/10 23:55
Please respond to
Anne.Anderson
In draft-xacml-schema-core-14b.xsd, the Target elements Subjects
and Resources are defined as follows:
<xs:complexType name="SubjectsType">
<xs:sequence maxOccurs="unbounded">
<xs:element ref="xacml:Attribute"/>
</xs:sequence>
</xs:complexType>
<!-- -->
<xs:complexType name="ResourcesType">
<xs:sequence maxOccurs="unbounded">
<xs:element ref="xacml:Attribute"/>
</xs:sequence>
</xs:complexType>
Presumably, the idea was that the Target "applied" if an
attribute that matched the specified Attribute
elements existed in the request.
Problems:
1. This does not provide a way to match on SubjectId or KeyInfo.
2. Are the semantics a requirement that the match occur on ALL
attributes or on ANY attribute?
3. What does "match" mean? Is it implicitly our "xacml:equals",
where the AttributeValue must be one of the types
"xacml:equals" is defined as applying to?
I don't feel particularly strongly about exactly how we resolve
these, but I think they must be resolved.
Recommendations:
1. Change the element definition from "xacml:Attribute" to
a combination of a pointer into the Request and a value that
the element at that pointer must match. something like the
following:
<xs:complexType name="SubjectsType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="RequiredAttributeMatch"
type="xacml:RequiredAttributeMatchType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="RequiredAttributeMatchType">
<xs:sequence>
<xs:element name="RequiredMatchingValue"
type="anyURI"/>
</xs:sequence>
<xs:attribute name="RequestValue" type="xs:string" use="required"/>
<!-- where string is an XPATH location path into the
Request -->
</xs:complexType>
Example: to say a rule applies to an AccessSubject that has an
RFC822Name SubjectID of "*.Simpson@Simpsons.com" AND at
least one subject has an Attribute with name "role" and value
"SystemAdministrator":
<Target>
<Subjects>
<RequiredAttributeMatch RequestValue="/Request/Subject
[@SubjectCategory="urn:...AccessSubject"]
/SubjectId[@Format="urn:...:RFC822Name"]">
<RequiredMatchingValue>
"*.Simpson@Simpsons.COM"
</RequiredMatchingValue>
</RequiredAttributeMatch>
<RequiredAttributeMatch RequestValue="/Request/Subject
/Attribute/AttributeMetaData[@AttributeName="role"]
/AttributeValue">
<RequiredMatchingValue>
"SystemAdministrator"
</RequiredMatchingValue>
</Subjects>
....
</Target>
2. Specify that ALL attributes within Subjects must match and ALL
attributes within Resources must match. I suggest this by the
name "RequiredAttributeMatch".
3. Specify that the matching operation is "xacml:equals", and
that the types of the value pointed to by the
AttributeSelector and the specified AttributeValue itself must
match and must be among the types supported by the definition
of "xacml:equals".
We could omit the RequiredMatchingValue and simply use XPATH
to specify the required element and its value. But then we
would be limited to exact string matches on request element
values, and we also could not use regular expression matching
on strings (which I assume xacml:equals will support).
Anne
--
Anne H. Anderson Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC