Role-Based Access Control Proposal for GForge Justin Richer July 2003 We would like to propose a new permissions system for GForge based on our previous customization work with a SourceForge 2.5 installation. Side notes are enclosed in [Square brackets], and all suggestions and comments are welcome. This system would allow for a generic and user-expandable permissions checking using the Permission object class in conjunction with its User and Group data elements. The function calls would be similar to what they are now, but more generic. Take for example the act of determining whether or not a user has access to create a new file release in the FRS: $perm->isReleaseTechnician() One would instead call: $perm->hasPerm("downloads", 2) which returns true if the user has level 2 or higher (also known as "Write" permissions, see levels explained below) for the "downloads" permission section. Each tool in GForge, including plugins (at the plugin author's discretion), would have its own section. [TODO: actual handling of plugins] Permissions are based on four possible levels for each tool. While the meaning of these four levels can vary with each tool (See Appendix: Tool-level permissions), it is easiest to think of the four levels as the following: 0 - None No access to any part of the tool. 1 - Read Can read existing elements, not edit 2 - Write Can create new elements and edit existing ones 3 - Admin Full administrative control over the tool [Note: perhaps we need more levels of granularity? With our project we got by on just these 4, but we may not want to limit it to that] Each higher level automatically subsumes all permissions of all lower levels. That is to say, one with Admin privileges can also Write and Read, etc. The setting of permissions would be based on a set of Roles, which would associated a set of Permissions to a given project. There are four roles predefined on the system: Administrator - Project admin, has level 3 access to everything Member - Project member, has level 2 access to everything LoggedIn - User with an account, but not member of group, has level 1 access to everything Guest - User with no account at all, level 0 access For small projects, these four default levels should suffice. Project Administrators do have the option of creating new roles with more complex access rules to create, for example, a forum moderator with no write access to CVS. [Note: An alternative approach would be to have Admin, Writer, Reader, and None as the above four Roles, and allow project admins to select which roles their new members get put into by default, as well as what roles are assigned to logged-in non-members and non-logged-in users, on a per-project basis. I'm currently thinking that this may actually be simpler to implement, too. Project admins would still be able to create any new roles that they wanted to for their project.] A Role is effectively a collection of permissions, which can be thought of as a grid, like this: Role: Foo 0 | 1 | 2 | 3 | ,---+---+---+---+ Tracker | | X | | | --------+---+---+---+---+ Forums | | | | X | --------+---+---+---+---+ CVS | | | X | | --------+---+---+---+---+ ... | X | | | | etc. When a user gets added to a project, the administrator must select the Role to place them into, which then determines what permissions they have around the site. Implementation -------------- The roles table would consist of: role_id - unique integer id for this role name - user-readable string name of the role ("Administrator", "Guest", etc.) The permissions table would consist of: perm_id - unique string id for this permissions set ("tracker", "cvs", "plugin_helloworld") name - user-readable string name of this permissions set ("Tracker", "CVS", etc) default - integer default level of the permission for a newly created role [also useful for handling plugins that get added at a later time, though plugins have the option of filling in roles_perms with their preferred default information however the plugin chooses] A user's Role within a group could be easily controlled using a new column the user_groups table, role, which would have an integer point to a role_id in the roles table. Roles would be associated with permissions using the roles_perms table. To get information for a given role, simply SELECT from this table based on the needed role_id: rp_id - unique integer association id role_id - integer pointing to the roles table perm_id - string pointing to the permissions table level - integer level of permission to grant this role on this tool Permission Sets Per Tool ------------------------ The list below describes the meaning of each level of permission available to each tool. We suggest that the permission set names (given in double quotes below the heading) mimic that found in the project_tabs function for the value of toptab. [Note: Perhaps there should be a global GForge registry of these tools instead of the usesCVS() usesMail(), etc, that get used currently, much in the same way plugins are handled?] Summary ------- "home" 0: None - No access to project (cascade down) - Searching will show name but not allow access 1: Read - Display Summary page and public information 2: Write - Edit public information 3: Admin - Project Administrator [Note: Perhaps project admin should be a separate thing, too? I don't think so personally, but I'd like comments] Forums ------ "forums" 0: None - No access to any part of the tool - Can't read, post, or monitor at all. 1: Read - read existing forums - monitor threads - save place in a thread 2: Write - can post replies - can start new threads 3: Admin - create forums - hide/unhide forums [make them member-only read/write?] Tracker ------- "tracker" 0: None - Cannot use any part of this tool. - Cannot see, edit, or create artifacts. 1: Read - Can browse individual Artifacts - Can view Artifact reports 2: Write - Can create Artifacts - Can edit Artifacts 3: Admin - Create new Artifact Types - Assign permissions to Artifacts - Assign resources to artifacts Lists ----- "mail" 0: None - Cannot see lists or edit them 1: Read - Can browse lists - Can browse archives 2: Write - Can edit lists - Can join a list 3: Admin - Can create new lists and administer the list server Tasks ----- "pm" 0: None - Cannot see tasks 1: Read - Can see list of tasks - Can view individual tasks - Can use task Reporting and Charts 2: Write - Can edit tasks - Can create new tasks 3: Admin - Can Edit, Create, and Update Sub-Projects - Can assign resources to tasks Docs ---- "docman" 0: None - Cannot see any of the documents 1: Read - Can see a list of documents - Can download documents 2: Write - Can add new documents - Can edit documents 3: Admin - Can add and edit document groups Surveys ------- "surveys" 0: None - Cannot see any surveys (including the main page) 1: Read - Can see and take surveys 2: Write - Can add, edit, and delete surveys - Can add Questions 3: Admin - Can see Survey results News ---- "news" 0: None - Cannot see news items (including main page) 1: Read - Can see list of news items - Can read individual items 2: Write - Can Submit news items 3: Admin - Can edit news items - Can delete news items - Can set permissions on news items [Note: There is a correlation between news items and forums that needs to be worked out with permissions] CVS --- [Note: this assumes some Chora integration, as Chora could actually pull the session and permission values in.] "cvs" 0: None - No access; can't browse, download, upload, anything. 1: Read - Can browse the archives online [Chora] - Can download any file/directory in the archive (export / anonymous checkout) - Can't check out as a user 2: Write - Can check in / check out files - Can delete/manage files - Can create new modules 3: Admin - Same as 2: Write Files ----- "downloads" 0: None - Cannot see released files (even on summary page) 1: Read - Can see list of files - Can download files - Can see information about individual files 2: Write - Can add/delete files - Can add/delete releases - Can edit files - Can edit releases 3: Admin - Same as 2: Write [Anything that we missed? People? Snippets? These may need their own special sections available only to site-admins]