Role-Based Access Control Proposal for GForge [Draft 2] 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->hasAccess("downloads", 6) which returns true if the user has level 6 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] The permission functions of isReleaseTechnician() and its ilk will still be available to existing code but should be considered depricated. These functions will be modified to call the appropriate hasAccess() call. In addition, there will be an aditional function requireAccess() that will call hasAccess() and exit with an error if the required permissions are not met. Permissions are based on ten possible levels for each tool, with four levels set aside for common permission settings. 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. 3 - Read Can read existing elements, not edit 6 - Write Can create new elements and edit existing ones 9 - Admin Full administrative control over the tool There will be several helper functions on the permissions class dealing with each of these levels directly: $perm->hasReadAccess("downloads") $perm->hasWriteAccess("downloads") $perm->hasAdminAccess("downloads") Note that an individual tool may define a higher level of granularity using the numbers in between these four levels, since 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. Each role has a project associated with it, and there are four global roles predefined on the system: Global->None - level 0 access to all tools Global->Reader - level 3 access to all tools Global->Writer - level 6 access to all tools Global->Admin - level 9 access to all tools All project have access to the global roles and may assign users as they see fit. 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. A role named 'Bar' created on the Foo project would be referred to as Foo->Bar with the appropriate access permissions set on it. Only an administrator of the Foo project has any access to use this role. A project administrator account automatically has the Global->Admin role assigned to it for that project. A site administrator ("super user") is still one with Admin access to the SiteAdmin project (group #1). A project administrator has the option of deciding not only what role each member of the project uses, but also what roles are assigned to both logged in users who are not members of the project and non-logged-in users. By default, these are both set to Global->Reader, though the defaults can be changed on a per-site basis. A Role is effectively a collection of permissions, which can be represented as a list of numbers designating the correct permissions level: Role: Foo->Bar .---------------. Tracker | 3 - Read | --------+---------------+ Forums | 6 - Write | --------+---------------+ CVS | 0 - None | --------+---------------+ ... | ... | 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 3: Read - Display Summary page and public information 6: Write - Edit public information 9: Admin - Project Administrator [ still debating on how to do project admin, exactly ] Forums ------ "forums" 0: None - No access to any part of the tool - Can't read, post, or monitor at all. 3: Read - read existing forums - monitor threads - save place in a thread 6: Write - can post replies - can start new threads 9: Admin - create forums - hide/unhide forums [make them member-only read/write?] - delete forum messages Tracker ------- "tracker" 0: None - Cannot use any part of this tool. - Cannot see, edit, or create artifacts. 3: Read - Can browse individual Artifacts - Can view Artifact reports 6: Write - Can create Artifacts - Can edit Artifacts - Can be assigned Artifacts 9: Admin - Create new Artifact Types - Assign permissions to Artifacts - Assign resources to artifacts Lists ----- "mail" 0: None - Cannot see lists or edit them 3: Read - Can browse lists - Can browse archives 6: Write - Can edit lists - Can join a list 9: Admin - Can create new lists and administer the list server Tasks ----- "pm" 0: None - Cannot see tasks 3: Read - Can see list of tasks - Can view individual tasks - Can use task Reporting and Charts 6: Write - Can edit tasks - Can create new tasks 9: Admin - Can Edit, Create, and Update Sub-Projects - Can assign resources to tasks Docs ---- "docman" 0: None - Cannot see any of the documents 3: Read - Can see a list of documents - Can download documents 6: Write - Can add new documents - Can edit documents 9: Admin - Can add and edit document groups Surveys ------- "surveys" 0: None - Cannot see any surveys (including the main page) 3: Read - Can see and take surveys 6: Write - Can add, edit, and delete surveys - Can add Questions 9: Admin - Can see Survey results News ---- "news" 0: None - Cannot see news items (including main page) 3: Read - Can see list of news items - Can read individual items 6: Write - Can Submit news items 9: 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 from the website more easily than another tool.] "cvs" 0: None - No access; can't browse, download, upload, anything. 3: 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 6: Write - Can check in / check out files - Can delete/manage files - Can create new modules 9: Admin - Same as 6: Write Files ----- "downloads" 0: None - Cannot see released files (even on summary page) 3: Read - Can see list of files - Can download files - Can see information about individual files 6: Write - Can add/delete files - Can add/delete releases - Can edit files - Can edit releases 9: Admin - Same as 6: Write [Anything that we missed? People? Snippets? These may need their own special sections available only to site-admins]