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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml-users] AttributeSelector usage


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=&quot;myattrid1&quot;]
> 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: 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]