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


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 <Anne.Anderson@sun.com> 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=&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]