[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-users] Reg. <ResourceContent>
Thanks for your answer Seth. Sometimes Subjects are Subjects and sometimes Subjects are resources:-) Ideally I would stick the xml representation of the "subject" if used as resource in <ResourceContent> or in <SubjectContent> as the case may be... Hope that gives some idea of where I was heading with my question... -prakash On Wed, 30 Mar 2005 21:52:28 -0500, Seth Proctor <Seth.Proctor@sun.com> wrote: > > On Mar 30, 2005, at 9:32 PM, Prakash Yamuna wrote: > > Section 6.4 states: > > [...] > > The key phrase that struck me was - "notional placeholder for the > > content of the resource" - hence my assumption that <ResourceContent> > > can be used only for xml content representation of resources. > > Your assumption is correct. Sort of. The ResourceContent element is the > standard place to include some or all of the content (ie, the resource) > that you're trying to access. Since it's being provided in XML > (typically), the content must be represented here in XML. That does not > mean, of course, that the original document must be in XML. It only > means that it must be representable here (as you say) in XML, so that > it can be queried. For that matter, the context does not physically > need to be XML, it just needs to hold to the required semantics, but in > practice the Request is often an XML document. > > What's the point? You may want to include rules in your policy that are > based on elements of the resource being accessed. One way to do this is > with designators, and then you either include the values in your > Request or have some custom handler in your context (in my > implementation, this is called an AttributeFinderModule) to pull the > value from the document. In an XML world it may be more natural to use > XPath, so a selector can be used instead, and the normative place to > look for values is in the ResourceContent. > > As Daniel said in his last email, there is no notion of a > SubjectAttributeSelector (etc.) since the ResourceContent values may be > applied as any kind of attribute. > > Getting back to your original question, I'm not entirely sure I > understand where you're going. What would a SubjectContent look like? > Or are you trying to create a new place to hold arbitrary subject > attributes in structured XML? > > > seth > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]