Modeling ACL requirement

[ConvertFromOldNGs]

by Anonymous >> Thu, 10 Mar 2005 11:33:45 GMT

I have a situation where I have a user that can belong to a set of groups. I also have items that belong to folders.

I need to model a scenario where I can get an ACLEntry class on both the Item and Folder class which represents the allowed facilities for a specific User object. Bear in mind that the amalgamted information will come form a specific user ACLEntry for the User and for the Groups the user belongs to.

Where the heck do I start from please. Do I have a list of acl entries for groups and an ACL entry for the User on the Item and Folder object with an accessor that combines the 2. Given this would also be the same for a Folder is it possible to model a more efficient solution.

I suspect the main issue is that, in database terms, the list of ACL entries is determined by the item (Item or Folder), the user and the groups they belong to. This is a none trivial relationship.

Many thanks
Ian Cox

[ConvertFromOldNGs]

by Robert Barr >> Fri, 11 Mar 2005 1:02:33 GMT

Ian,

Here's hoping I've understood what you are attempting to do ...

If you are starting from scratch with a new database, then the attached model may offer somewhere to start. Database entities are either "Accessing" (user or group) or "Access Controlled" (item or folder) entities.

For a particular "Accessing" object to have access to an "Access Controlled" object, there must be an ACLEntry object which belongs to each of their corresponding aclEntries collections, or to one of their parents' aclEntries collections (e.g. a user's parent groups, or an item's folder).

As you say, you will need an 'accessor' method to perform this checking, and determine if an appropriate level of access exists, this could have a signature like this:

AccessingEntities::isAccessPermitted(
accessControlledEntity : accessControlledEntities;
requiredAccessLevel : Integer) : Boolean;

// return true is access is allowed, otherwise access is denied.
// check acl list, accessControlledEntity and
// accessControlledEntity's parents,
// then ask each group to check it's acl list ...

If your ACLEntry objects support different levels of access, including access restrictions (e.g. access denied), then you may require some rules to determine precedence when two ACLEntries conflict).

This model will still work if group membership and folder membership is recursive, i.e. users belong to groups, which in turn belong to groups ... etc.

Cheers,
Rob

[ConvertFromOldNGs]

by Ian Cox >> Fri, 11 Mar 2005 8:26:06 GMT

Rob,

Excellent, I was nearly there, I just did not think about the User and Group being derived from AccessingEntities and holding the ACLEntry's at that level.

Many thanks
Ian Cox

[ConvertFromOldNGs]

by Ian Cox >> Fri, 11 Mar 2005 15:13:07 GMT

Okay so I lied! I'm still confused! I think I have a solution but may well be barking up the wrong tree (no pun intended).

Caveat,
I'm new to Jade and I am assuing that if I check for the accessor on the ACLEntry being equal to 'self' then I will locate the ACLEntry for the Entity which refers to the User or Group doing the checking. If not, this all falls apart.

Firstly there is a slight complication here as an ACLEntry will have several flags indicating if an Accessor can Edit, Read, List, Author, View Perms, etc.

I think the aclEntries collection only needs to exist on the AccessControlledEntities. This means we need a reference for the AccessingEntities type of object on the ACLEntry. This will allow us to either store a User or a Group object on the ACLEntry. Surely if we have 2 lists then the ACLEntry will need a reference to both an Accessor and Entity in order to be usable.

The accessor then resides on the AccessingEntities class and accessed via the User object and is passed an Entity object. The User object will represent the current user and is probably a SharedTransient. The method will scan the entities ACLEntries for a record pertaining to itsself then ask each of the Users Groups to do the same, merging the results of each check. The merge woud apply the presidence rules to handle conflicting settings.

If there are any unresolved settings then the process is repeated with the passed entities parent entity. So Item would pass to owning folder and a folder would pass to parent folder until we reach the top of the structure. at that point we apply 'default' settings to those remaining attributes.

To add a User or Group to the ACL we have a method on the AccessControlledEntities which is passed an AccessingEntities or more probably a completed ACLEntry record.

I have attached an image of what i am talking about if it helps.

Many thanks
Ian Cox

[ConvertFromOldNGs]

by Robert Barr >> Mon, 14 Mar 2005 1:22:15 GMT

Ian,

Caveat noted ... no problem.

Sounds good, except that you don't have to have to look up the ALCEntry in a global ACLEntries list (excuse me if I've misunderstood where your coming from here) - Jade allows individual User objects to have their own 'embedded' collections (or lists), so you can define the ACLEntry list (collection) on AccessingEntities. So when you add an ACLEntry, it is added to the persistent AccessingEntities (User or Group) object's list. It is also stored in the AccessControlledEntity's list - it defines the accessibility relationship between the two objects, so it may as well 'live' on these objects.

On a bit of a tangent, when updating persistent objects in the database (e.g. adding or changing ACLEntries), it's worth considering use of a model/agent architecture. Have a look at the Erewhon demo system (and design doco) on the Jade web site for a good example of how this can be implemented in Jade.

Cheers,
Rob

[ConvertFromOldNGs]

by Ian Cox >> Mon, 14 Mar 2005 15:54:46 GMT

Rob,

Okay so I think I now know where this is going.

1) define myAccessor and myEntity on the ACLEntry class
2) Make each attribute have an inverse that is the aclEntries collection on the AccessingEntities and AccessControlledEntities

To add an aclEntry from either side

1) Create an ACLEntry persistent
2) Set the reference to myAccessor and myEntity along with the relevant flag settings

Now we can check the User aclEntries to see if they have access to an object (check myEntity against a supplied entity object) and from the Entity we can check if a User or Group has access my checking the myAccessor against a supplied accessor on the entities (Folder/Item) aclEntries collection. The getEffectiveACL call taking crae to look at the User and their groups, etc.

Complete flexibility with minimum of fuss. Am I correct or still up the wrong tree!

Regards your tangent I intended to adopt your suggestion. I have seperated the 2 in my developments for some time with VB and ASP solutions. Thanks for the pointer to the demo. Will look closer at that.

Thanks again
Ian Cox

[ConvertFromOldNGs]

by Robert Barr >> Tue, 15 Mar 2005 2:29:38 GMT

sounds like the right tree to me - good luck

[ConvertFromOldNGs]

by FF >> Tue, 6 Dec 2005 17:29:07 GMT

www.frank-feigel.de

[ConvertFromOldNGs]

by FF >> Thu, 8 Jun 2006 6:27:50 GMT

FFeigel@t-online.de

[ConvertFromOldNGs]

by FF >> Thu, 8 Jun 2006 6:29:55 GMT

FFeigel@t-online.de