RIF: [Gforge-devel] RBAC Proposal

[SPISSER REINHARD]

I've added my comments in ******Reinhard *******



Role-Based Access Control Proposal for GForge
 Justin Richer <jricher @ mitre . org>
 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)


*** Reinhard I find the isReleaseTechnician() call more human-readable. We can 
just change
the isReleaseTechnician() method to call hasPerm("downloads",2). 
We should also use symbols instead of numbers (hasPerm("downloads","Write")), 
which
is more human-readable than a number.*****

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



**** Reinhard
Something like the previous "technician" should be inserted. This user can 
update only a part
of information. 

I've already implemented the None option on my local machine.... A "Own" option
also exists for the tracker where the user can see only his own tracker 
items(useful for customers)
*****

[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.

***** Reinhard
This is true only if an option like "own" is not implemented. Otherwise a 
distinction between
"Tool functionality" and "data visibility" must be made. 
*****

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.]


*** Reinhard
Site administrators should be able to create new global roles.
Global roles should be distingueshed from local project roles to
avoid name conflicts.
So "global" roles should be called "global->Administrators", "global->Member", 
etc.
Local rules for project test should be called "test->Admins", 
"test->Customers",etc



****

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 informationn
*******display also information about "authorized" tools, like tracker, pm, etc.
****
  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?]
****
delete forum messages
*****


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

***Reinhard

Only Admins should be able to see reporting and charts
or we should add a role "reports" which permits to see reports

****


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]


*****Reinhard

Snippets
----
   0: "None"
     - Cannot view snippets
   1: Read
        - can read snippets
   2: write
      Can create/update snippets
   3: admin
        Can create/update/delete snippet packages, delete snippets
******


******
Reinhard
How will the actual permissions fit to this new roles?

*****





-----Messaggio originale-----
Da:     Justin Richer [mailto:address@hidden
Inviato:        ven 25/07/2003 21:22
A:      GForge Devel
Cc:     
Oggetto:        [Gforge-devel] RBAC Proposal
As it seems to be a feature that many people are interested in, the
first major piece of work we've decided to tackle is the RBAC system.
I've attached a first draft at a proposal for an RBAC system for GForge.
I currently don't see a way to make it an 'optional' piece, but if the
defaults are set right, then not much will change from a current default
GForge installation. Please comment, suggest, anything! This is still in
the planning stages, all input is welcomed.

  -- Justin