EditAttachWiki Help
r13 - 07 Feb 2006 - 15:27:14 - LisaDusseaultYou are here: OSAF >  Journal Web  >  ProductManagement > ProjectOverviewTable2005 > CanogaAccessControlListDesign

Canoga Access Control List Design

Contents

Summary

Whenever Chandler repository data is accessed remotely, we need an appropriate security model to make sure only intended remote users with the right privileges access and edit the repository data. We use Access Control Lists as the security model in Canoga and this document describes the details of the Canoga access control list model.

Terminology

  • Permission Level - A privilege or right that an authenticated user has. It is usually used in the context of an AccessControlList attached to a shared item or View, in which case the permission level determines the rights of particular user(s) to the remote item or view.
    • In Canoga, we have 3 permission levels:
      • Private: No remote access is permitted for this item or collection
      • Read-only: Can only be viewed, not edited
      • Editable: Read, write, create and delete privileges as well as the ability to further give (or revoke) other users permissions on the unit of sharing. Also ability to delete the unit of sharing.
      • [Note as of 30 Mar 2004, we removed "Admin" privileges and collasped its privileges with "Editable"]
    • See also CanogaAccessControlListDesign? for application of PermissionLevel

Use Cases and Design Motivation

Use cases related to access control lists are all sharing use cases. Also related are any use cases that use the Chandler repository as a platform and require access to a remote Chandler repository through some as-yet-undesigned API.

We are taking a "liberal" approach to permissions and access control. We observe that the OSAF wiki is open to everyone, and there have been only a handful of cases where we had to intervene to restore wiki content. This motivates us to keep the permission levels simple (private, read-only, editable) but coarse-grained.

Structure

Workflows

Feature List

# When Feature Description
1 Canoga Owner is root The repository owner is automatically an administrator for everything shared on the repository. In addition, the owner can also confer any individual user or group belonging to the owner's Chandler Contacts the above permissions for each instance of sharing.
2 Canoga Public access PublicUser is permissible in an Access Control List. This allows the owner to share a view to all Chandler users.
3 Canoga Private items An item can be marked as private. If an item is private, then it will never be shared, under any circumstances.
4 Canoga Private Item overrides View ACL If an item is marked private and is contained in a shared view, that item does not appear in remote views i.e. the item's privacy attribute overrides the permission settings on the view
5 Canoga Items and Views cannot be re-shared directly A shared item or view has exactly one access control list attached to it. A remote user cannot add her own separate ACL to the remote item or view. A remote user can allow other users to access this item, if she has Admin privileges
6 Canoga "implicitly shared" connected items If I grant someone access to item A, and item A has a connected "implicitly shared" item B, then that person also has access permission to item B. See ItemLinksAndSharing
7 Canoga Four levels: Private, Read-only, Editable, Admin In Canoga, we have 4 permission levels, as listed in PermissionLevel

Open Issues

# Feature Description
1 Can items be re-shared in other Views? A shared remote item can be added to another collection. That collection in turn would have a separate ACL, which can allow completely different people from accessing the new collection and hence, the same remote item.
Privileges to this remote item would be the intersection of the ACL specified in the new view and the ACL specified in the old view, whichever is less liberal. Mimi suggests we allow this only if new collection owner has admin privileges to old collection

Notes

Contributors

  • ChaoLam - 22 Mar 2004

Comments Welcome

A use case that may not be covered by the levels mentioned above is when someone needs to add a calendar or todo item for someone else, e.g. an administrative assistant should be able to insert items and view items but not necessarily delete or edit items.

-- MikeT - 31 Mar 2004

Projects.PageInfo
Projects.PageType DesignOverviewPage
Projects.MaintainedBy ChaoLam
Projects.PageStatus Proposal -- available for review?
Trash.CommentsWelcome2 Feel free to contribute comments?, either by adding to the Comments Welcome section of this page, or by posting to the dev list, or by sending mail directly to the person listed as maintaining the page.
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r13 < r12 < r11 < r10 < r9 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.