Anne,
I do have my own functions and my own datatypes. My functions supports
taking those datatypes as input.
So strictly speaking a standard XACML implementation should work -
after all it has to call my datatypes to construct the attribute
value.
But the problem is the way the spec is worded - you cannot point it to
an element node. If it does then a standard XACML implementation would
find the string representation of the element node (or atleast that is
my understanding)
Well i certainly could stick all my data as text and do a string
regexp match - but in that case why even have support for xmlfying the
resource info/subject info?
w.r.t. your question on new datatypes - this is a non-standard case. I
am trying to send the groups to which the subject is a member along
with the subject information.
thanks,
prakash
On Wed, 09 Mar 2005 09:56:52 -0500, Anne Anderson <> wrote:
> Hi Prakash,
>
> XACML extensibility certainly allows you to do what you outline below,
> although you would have to add code to support your new function and its
> assorted new datatype to your XACML implementation.
>
> You quote the XACML 2.0 spec:
>
> > The data-type of the contents of the <xacml-context:AttributeValue>
> > element. This SHALL be either a primitive type defined by the XACML
> > 2.0 specification or a type (primitive or structured) defined in a
> > namespace declared in the <xacml-context> element.
>
> That applies to standard implementations of XACML. You are certainly
> free to extend XACML to support additional types of your own; it is just
> that you should not expect standard XACML implementations to support
> your types - they would have to be enhanced.
>
> I'm curious, however, about what new datatypes you want, and what new
> functions you need. A string-regexp-match can be used on most types of
> data if you want to find a match, even if the data has non-string
> semantics. To the extent that you can make use of the standard types
> and functions, your policies will be interoperable with more PDPs.
>
> Anne Anderson
>
> Prakash Yamuna wrote:
> > The spec (2.0) states the following for <AttributeSelector>:
> >
> > Each node selected by the specified XPath expression MUST be either a
> > text node, an attribute node, a processing instruction node or a
> > comment node. The string representation of the value of each node MUST
> > be converted to an attribute value of the specified data-type, and the
> > result of the AttributeSelector is the bag of the attribute values
> > generated from all the selected nodes.
> >
> > Does that mean I cannot have something like this?
> >
> > <Request...>
> > <Subject>
> > <Attribute AttributeId="myattrid1" DataType="mydatatype1">
> > <AttributeValue>
> > <test:MyElementName>
> > blah blah
> > </test:MyElementName>
> > </AttributeValue>
> > </Attribute>
> > </Subject>
> > ....
> > </Request>
> >
> > And then in the Policy I do something like:
> > <Policy...>
> > ....
> > <Apply FunctionId="myfunc1">
> > <AttributeSelector
> > RequestContextPath="//Subject/Attribute[@AttributeId="myattrid1"]
> > DataType="mydatatype1"/>
> > ....
> > </Apply>
> > ....
> > </Policy>
> >
> > This seems counter intutive to me in that the schema is open enough to
> > allow embedding my own structure into the AttributeValue but I cannot
> > leverage it in a meaningful manner in the AttributeSelector.
> >
> > Also I am trying to understand how the ability to plug in an arbitraty
> > structure into <ResourceContent> works given the limitations on the
> > AttributeSelector?
> >
> > Also the spec states the following:
> >
> > DataType [Required]
> >
> > The data-type of the contents of the <xacml-context:AttributeValue>
> > element. This SHALL be either a primitive type defined by the XACML
> > 2.0 specification or a type (primitive or structured) defined in a
> > namespace declared in the <xacml-context> element.
> >
> > So what would be the value of defining my own (complex) datatypes in
> > such a scenario?
> >
> > Am I missing something?
> >
> > Also any inputs on how one can overcome this limitation would be
> > greatly appreciated.
> >
> > thanks,
> > prakash
>
> --
> Anne H. Anderson Email:
> Sun Microsystems Laboratories
> 1 Network Drive,UBUR02-311 Tel: 781/442-0928
> Burlington, MA 01803-0902 USA Fax: 781/442-1692
>
>
