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

[Anne Anderson <Anne.Anderson@sun.com>]

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;
> 
> -----Original Message-----
> From: Anne Anderson [mailto:Anne.Anderson@sun.com] 
> Sent: Thursday, March 16, 2006 8:44 AM
> To: OASIS XACML TC
> Subject: [xacml] Questions on "Introducing attribute categories"
> 
> RE: http://lists.oasis-open.org/archives/xacml/200603/msg00002.html
> 
> Two comments, plus one stated by Erik:
> 
> 1. Section 2.2 says [Current specification ... defines] "Resource
>     category  Multiple resource groups may be specified in request"
> 
>     Is this referring to the "Multiple resources profile"?  Otherwise
>     the current specification allows for only one group of attributes
>     for one resource.
> 
> 2. Section 4.1 says [In this proposal, in the Request schema]
>     "<Resource> and <ResourceContent> elements are preserved, so that
>     path expressions used to identify parts of the resource content
>     in XACML 2.0 need not be changed."
> 
>     I don't see why these are kept when <Subject>, <Action>, etc. are
>     changed, and path expressions used to identify parts of XML
>     element-valued Attributes in those other sections will have to
>     change.
> 
>     While we are at it, is there a good reason why "ResourceContent"
>     can't be an XML element-valued Attribute just as Subject, Action,
>     and Environment Attribute values that are XML elements are?
> 
> 3. This comment comes from Erik: For the delegate category, we need
>     a way to distinguish a category not being present from a particular
>     Attribute not being present.  Lack of a delegate category is how
>     an access policy is distinguished from an administrative policy.

-- 
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