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: Design advice

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 

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

thanks for any advice,


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