Notes on Access Control

Return to Development: Documentation & Tips

Changes to access further up the tree should affect subtrees through inheritence i.e. on paths

/user/douglm/special/calendar1 /user/douglm/special/calendar2

Setting access to read, authenticated on special should allow all authenticated users to read calendar1 and calendar2.

However a specific access to calendar2 of none, johnsa should make calendar1 unreadable to johnsa but not anybody else.

Also a specific access to special of none, johnsa should make calendar1 and calendar2 unreadable to johnsa but not anybody else. In addition if I add /user/douglm/special/calendar3 it should automatically take the same access rights, i.e. johnsa has no access.

What if I already set none,schwag on 'douglm', that is set the default access for all my stuff to none, schwag?

It seems that to calculate access we need to go up the tree accumulating SPECIFIC access rights till we reach the root - which has the default access.

At that point we determine the access the user has based on those acls.

We should set a flag in the acl indicating if this is an inherited acl. Webdav likes to know this. Also when a user is chaging access they want to know if the current access is inherited or set in the object. They may want to isolate an object from changes above it by explicitly setting access rights.

Also, we need a lot of caching - this is a frequent operation. Within a single request, we can build a table of calculated acls with the path (and owner) as the key.

Don't forget the case of referenced events. We may be looking in

/user/douglm/special/calendar1

but the actual event may be in

/user/johnsa/calendar

(Isn't it the case though, that the path defines the owner)

The frequent searches are going to be for BwCalendar objects. These should be cached by hibernate. In additon we should cache all calculated acls for a given path, along with a checksum of some kind - the sum of the seq values on the path maybe. We could get the whole path - if the sum is the same don't rebuild acl.

Process for checking access becomes something like:

• Check the table for the merged access for the current path. For an event the path is that of the containing calendar. For calendars it's the path to the object itself.

• If the path does not exist, create a merged Acl and add it to the table.

• For an event if there is any access info in the event create a merged acl.

• For an event with no access info or a calendar just use the path acl.

• Check the access against the acl. This step can be optimised further by keeping the result of checks against that path with that principal.