MHonArc v2.5.0b2 -->

















xacml message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Re: [xacml] Questions on "Introducing attribute categories"




From: Anne Anderson <Anne.Anderson@sun.com>
To: Daniel Engovatov <dengovatov@bea.com>
Date: Thu, 16 Mar 2006 14:07:18 -0500






Hi Daniel,

Daniel Engovatov wrote On 03/16/06 13:51,:
> 1. Yes, this is for multiple resources profile.
> 2. I thought that the main use case is for a resource being a general
> XML document - we also refer to this in hierarchical resources profile.
> It seems to me that this is a use case that is quite distinct.  
> 
> As far as specifying it as an attribute value - interesting - but for
> the rest of attributes we usually do have an atomic data type defined,
> while this is complex content.  How would you refer to its data type in
> the designator?

The data type is the urn of the top element in the value.

> P.S. My personal preference is for this to be defined as a completely
> separate piece:  you have a request document specifying attributes to be
> retrieved by an attribute designator, and you provide an arbitrary XML
> document separately that is the base for attribute selector.   That gets
> rid of "any" content, also makes strong typing for this XML context
> evidence easier to define.

Supporting access to XML documents where the access policy depends on 
the content of the document is a core XACML requirement.  I think it is 
very important for us to continue to define how such information can be 
referenced as part of our core Request Context, even if we change the 
way in which such information is referenced.

XML documents describing a Subject have arisen in several use cases sent 
me by users.  For example, a Subject may belong to multiple groups and 
may play different roles in each group.  It is easy to define an XML 
schema that lets the Subject be described as:

<Attribute AttributeId="SubjectInfo" DataType="ns:SubjectInfo">
  <AttributeValue>
   <ns:SubjectInfo>
      <Group GroupId="1">
         <Role>manager</Role>
         <Role>administrator</Role>
      </Group>
      <Group GroupId="2">
         <Role>member</Role>
      </Group>
      <Group GroupId="3">
         <Role>manager</Role>
      </Group>
      <Group GroupId="999">
         <Role>water person</Role>
         <Role>substitute player</Role>
      </Group>
   </ns:SubjectInfo>
  </AttributeValue>
</Attribute>

Now, an AttributeSelector can be used to see if a Subject has role 
"manager" in Group 3:
<Apply FunctionId="string-is-in">
   <AttributeValue DataType="string">manager</AttributeValue>
   <AttributeSelector 
RequestContextPath="//Request/Subject/Attribute[@AttributeId="SubjectInfo]/Group[@GroupId="3"]/Role/text()"
DataType="string"/>
</Apply>

I have also seen use cases for XML schema elements used to describe a 
Resource (not the content of the Resource).

Anne
> 
> I do not have a strong opinion on this issue though - let's keep it open
> until we are ready to edit the hierarchical resources profile.
> 
> Daniel;
> 
>