re: Design advice

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

Hi Adam,

Via the ContextHandler, based on the requested document's resource-id 
Attribute, presumably you could retrieve the document's owner group and 
assignee(s).  Then, based on the Subject's subject-id, you could 
retrieve the subject's roles within that particular group.  Now the 
policy could be of the form:

    Target
       action="reassign"
    Rule Effect="Permit"
       "Administrator" is-in AttributeId="role"

    Target
       action="modify"
    Rule Effect="Permit"
       or (
       "Administrator" is-in AttributeId="role",
       "Editor" is-in AttributeId="role" )
       AttributeId="subject-id" is-in AttributeId="document-assignee" )

It might be possible to present the Subject information to XACML using 
an Attribute having an XML element value like the following (omitting 
DataTypes and without checking syntax):

   <Subject>
     <Attribute AttributeId="SubjectInfo" 
DataType="<namespace>:SubjectInfo">
      <AttributeValue>
        <SubjectInfo>
          <Group GroupId="X">
            <GroupRole>Administrator</GroupRole>
            <GroupRole>Editor</GroupRole>
          </Group>
          <Group GroupId="Y">
            <GroupRole>Contributor</GroupRole>
          </Group>
        </SubjectInfo>
      </AttributeValue>
    </Attribute>
    ...

   <Resource>
     <Attribute AttributeId="DocumentOwner">
       <AttributeValue>X</AttributeValue>
     </Attribute>
   ...

then use AttributeSelectors with RequestContextPath values that use 
XQuery functions to select only the GroupRole values that fall under 
Group elements having a GroupId that matches the "DocumentOwner" 
Attribute's value.  I don't know enough XQuery language to know if that 
can be done, however, and even if XQuery could do it, I don't know if 
any of the available XACML implementations would support it.

Anne

 > Hi, I'm just learning about XACML and I'm trying to figure out
 > how I might implement our application's access-control model
 > (backdrop: this question was originally posed on the list for
 > Sun's Java implementation, which is what we're thinking about
 > using -- apologies to anybody who's gonna see it twice!)
 >
 > The basic setup is this: we have a documentation management
 > system in which there is a many-many relationship between users
 > and groups.  A wrinkle is that users may play different roles
 > in different groups, and access control policies are
 > role-dependent.
 >
 > There are administrator, editor, and contributor roles.  That
 > is, a member of a given group might be an editor for that
 > group.  In another group, he might be a contributor, and in yet
 > another, he might be an administrator.
 >
 > Documents are owned by groups, and are *assigned* to specific
 > members of the group.
 >
 > Let's focus on two operations: modifying a document's contents,
 > and reassigning a document to a different user.  The global
 > policy that applies to all documents, then looks like this:
 >
 > * Admins are superusers with respect to the documents owned by the
 >   groups (modify + reassign privileges).
 > * Editors may modify any document owned by the group, but not
 >   reassign them.
 > * Contributors may only modify documents assigned to them.
 >
 > All information about
 >   - ownership
 >   - assignment
 >   - group membership
 >
 > is available through the application's data model.
 >
 > In the abstract, it seems to me that the right attribute to key
 > on in requests and policies would be an attribute expressing
 > the subject's *relation* to the document:
 >
 > 1) No relation (the user is not a member of the group that
 >    owns the document)
 > 2) Assignee (the user is a contributor in the group, and is
 >    assigned to the document)
 > 3) Editor (the user is an editor in the group that owns the
 >    document)
 > 4) group administrator (the user is an administrator in the
 >    group that owns the document).
 >
 > (questions about a user's relation to the thing she's trying to
 > modify can be answered by consulting the model; one of the
 > worries I have concerns performance, since the data model will
 > need to load a number of objects up in order to determine the
 > relations)
 >
 > So!  Now finally to the question: is the "relation" abstraction
 > the right way to go?  Would you need more information to answer
 > the question?

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