| Re: [stellation-res] Access Control Lists |
Sorry I took so long to get to replying to this. Things have been insanely busy lately. On Tue, 2002-09-10 at 04:00, Jonathan Gossage wrote: > I have had a look at the spec and I have a number of thoughts. > > 1. I think you can simplify the UML diagram and hence the underlying model > by removing "Permission Grant". In this view a "privelege Set" would grant > privileges directly to an "Access Control Group" and an "Access Control > Entry" in an ACL would directly grant access to a controlled object > (Repository, Branch or Access Control Group). To me the relationship between > "Privilege Set" and "Access Control Group" should be one of containment and > the granting relationship should exist directly between an ACE and a "Access > Control Group". The UML diagram is really more my idea for how things will be layed out in the database than for how things will appear in the Java code. Each permission grant is a row in a database table, associating a permission set with an ACL ID. On the other hand, in your description above, I have a bit of trouble understanding how an "Access control entry" differs from a PrivilegeGrant. It seems that each one is a member of an ACL granting a set of privileges over a particular controlled object. > I would consider providing a seperate ACL for each repository object to be > protected. This would yield a 1:1 relationship between an ACL and a single > controlled object. This is something that I'm debating. It ultimately relates to the correct behavior of inherited privileges. The question is, when you modify the ACL of the parent object, and the child hasn't ever modified its ACL, should that modification to the parent be inherited by the child? I like that in concept, but I'm not overly fond of some of the implementation implications. > 2. I like the concept of inherited privileges. It nicely allows an > organization to support a open policy where most privileges are granted by > default or a restrictive policy where privileges are only granted on an as > needed basis. > > 3. I think that you will need the following capabilities in the API that > grants access to controlled object for groups. > > a) Add a specified list of "Access Control Groups" to an ACL. > b) Add all but a specified list of "Access Control Groups" to an ACL. > c) Remove a specified list of "Access Control Groups" from an ACL > d) Remove all but a specified list of "Acccess Control Groups" from an ACL. > > It is essential that a remove operation does not result in a situation where > there is no group with the privilege to modify the ACL. That can never happen: there is the administrator group, which always holds all privileges to all controlled objects. > 4. I would describe the set of privileges that a individual user has on a > specific controlled object as follows. > > a) Compute the intersection of the user and the "Access Control Groups" in > the ACL controlling an object. > b) Compute the union of the privileges granted by the ACG's in the > intersection. That sounds right. -Mark -- Mark Craig Chu-Carroll, IBM T.J. Watson Research Center *** The Stellation project: Advanced SCM for Collaboration *** http://www.eclipse.org/stellation *** Work Email: mcc@xxxxxxxxxxxxxx ------- Personal Email: markcc@xxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part