OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: re: Design advice

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:

    Rule Effect="Permit"
       "Administrator" is-in AttributeId="role"

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

     <Attribute AttributeId="SubjectInfo" 
          <Group GroupId="X">
          <Group GroupId="Y">

     <Attribute AttributeId="DocumentOwner">

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.


 > 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]