FusionForge

RBAC

From FusionForge Wiki
Revision as of 10:10, 26 April 2014 by Beuc (talk | contribs) (Roles)

Jump to: navigation, search

FusionForge uses the Role-Based Access Control or RBAC model for permissions.

Users don't have direct permissions; instead they have roles and each role has permissions.

When a user requests a restricted action, her roles are checked: if one of her roles has the required permisson, the action can go on. If none of her roles have the permission, the action is denied by default.

This RBAC implementation was designed as part of the Coclico project and more formally documented on planetforge.org.

Roles

Roles have a class:

  • Implicit roles: hard-coded, applies on a whole class of users:
    • LoggedIn: grant rights to people with an account
    • Anonymous: always available, to anonymous (non-logged-in) and identified users (cumulative with their other roles)
  • Explicit roles: directly assigned to a particular user. They can group users with similar permissions.

Roles also have a scope:

  • Global roles are not attached to a project in particular, they are forge-wide. This includes implicit roles. They also typically include a Forge admin and News admin role, configured to grant permissions on forge site administration and front page news approval respectively.
  • Project roles are created within a project, e.g. a different role for project admins, developers, managers, trainees, tech support, and so on. When a user is assigned role(s) in a project, she's considered as a member of the project.

Recap:

  • implicit & global (anonymous, loggedin)
  • explicit & global (forgeadmin, newsadmin, ... ; per-user)
  • explicit & !global (for a particular project ; per-user)

Permissions sharing between projects

Project roles and global roles can be "shared", which allows referencing ("linking to") them in other projects, so that permissions granted to one role in a project can be "delegated" automatically in other depending projects. For instance, one may want to define a list of staff members; that list can be described as an explicit global role (a list of users). If that role is shared, a project can reference it and grant it permissions (for instance, commit access), and not have to update membership when new people join the staff, or when employees leave. This may also be used for projects / subprojects links, where all project admins are automatically admins of subprojects, etc.

Permissions

Permissions are defined on a "tool". For project tools such as trackers, the project admin can configure the permissions on the tool for each of the roles that are referenced by the project; that includes the project's own roles, of course, as well as the external roles (global or coming from another project). There are a few "global" permissions, such as approval of projects, approval of news to the front page, and forge administration. These global permissions can only be granted to global roles (by a forge admin, i.e. someone with the forge administration rights).

Note that some permissions automatically grant others: a role with the "project admin" permission will have all the permissions on all the tools of the project, so there's no point in adding or removing individual permissions on trackers from that role; similarly, the "forge admin" permission gives all permissions on all parts of the forge, so there's no need to grant individual permissions.

Permissions related to anonymous access, or access for non-members, are handled with the Anonymous and LoggedIn roles, respectively. As a consequence, unreferencing the Anonymous role from a project effectively makes that project unavailable for people not logged in.

Pre-defining roles in Project Templates

Project templates are the place to define pre-defined project roles for various classes of users with different permissions, so that these will apply automatically to projects created from these templates.

For instance, a forge admin may prepare two templates : "Public Project Template" and "Private Project Template", for "public projects" and "private projects" resp. so that the visibility of the project to anonymous and logged in (non-member) users are respectively set to "visible" and "hidden". Thus, all projects created reusing these visibility permissions set in those templates will be either visible or hidden, only accessible to their members (i.e. those with another explicit role in the project, typically set with a "visible" visibility.

Also, one may typically wish to define more roles corresponding to non-admin members and admin members of the project. The default Project Template does only provide such an Admin role.

Should you wish to customize a project template so that its roles are similar to the traditional roles of gforge/fusionforge up to 5.1, there's a populate_template_project.php script ready for you.