Re: [xacml-users] Reg. <ResourceContent>

[Prakash Yamuna <techpy@gmail.com>]

Thanks Anne - in some ways that is what I am doing - but it is not so
coarse grained  because - AttributeSelector has limitations in terms
of what I can select using XPath - my policies need more fine grained
XPaths but unfortunately these point to elements not text...

The other thing is I could have used Java to XML binding tools to bind
the XML fragment to java objects - thus obtaining typing - without
having to write custom Attribute classes.

But this discussion has definitely given me a better understanding for
the origins of <ResourceContent>.

Thanks to everyone for your responses.

prakash
On Thu, 31 Mar 2005 08:20:20 -0500, Anne Anderson <Anne.Anderson@sun.com> wrote:
> Prakash,
> 
> The context node for the XPath expression in an AttributeSelector is the
> entire xacml-context:Request element (XACML 2.0, Section 5.42).  This
> means you are free to define new Subject, Action, and Environment
> Attributes called, for example, "urn:...:SubjectContent",
> "urn:...:ActionContent", and "urn:...:EnvironmentContent", and specify
> that these Attributes are for holding XML schema instances that describe
> the Subject, Action, and Environment.  You can use AttributeSelectors to
> access content from these new Attributes just as you can for an XML
> schema instance in the ResourceContent element.  Maybe this is what you
> meant by saying "create custom Attributes", but I wasn't sure.
> 
> As Daniel says, I believe the main reason we defined a special
> ResourceContent element, rather than letting this information be in a
> Resource Attribute, is that XACML was originally designed to protect
> access to XML documents, and was then extended for more general use.
> 
> Anne
> 
> Prakash Yamuna wrote:
> > Well frankly what I would have preferred is having some predefined
> > buckets maybe like :
> >
> > <Request>
> > <SubjectContent>...</SubjectContent>
> > <ResourceContent>...</ResourceContent>
> > <ActionContent>...</ActionContent>
> > <EnvironmentContent>...</EnvironmentContent>
> > </Request>
> >
> >
> > Then use AttributeSelector that supported retrieving both text
> > (attribute, cdata, etc) and elements that also takes in the datatype
> > for the XPath - thus retaining typing.
> >
> > It lowers the barrier to support XACML and would have kept things very
> > simple in my mind - but then again I maybe wrong:-)
> >
> > prakash
> >
> > On Wed, 30 Mar 2005 22:25:09 -0500, Seth Proctor <Seth.Proctor@sun.com> wrote:
> >
> >>On Mar 30, 2005, at 10:12 PM, Daniel Engovatov wrote:
> >>
> >>>>In general, however, I think this is
> >>>>cleaner than defining a catch-all section where you can dump
> >>>>XML-encoded data. That's just my opinion..
> >>>
> >>>Actually, IMHO, a catch-all section for the context representation is a
> >>>very good idea.   Just stick it separately from Resource and name it
> >>><CONTENT>.
> >>
> >>I think you conflated two ideas here. I was talking about taking the
> >>existing structure, but adding a section to Subject, Action, and
> >>Environment that lets you dump _XML_ data. I don't like this idea. I
> >>was not talking about changing the complete context representation.
> >>
> >>
> >>>Getting down that road - Subject, Action etc are not really needed
> >>>either.  They are just for ease of management. Should be just some,
> >>>maybe predefined, extensible "buckets" - to associate with various data
> >>>sources.  :)
> >>
> >>They're not needed, but I think they're very useful in practice. "Ease
> >>of management" should not be taken lightly :)
> >>
> >>
> >>seth
> >>
> >>
> 
> --
> 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
> 
>