[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: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]