Difference between revisions of "RBAC"

From FusionForge Wiki
Jump to: navigation, search
(Description of RBAC)
(No difference)

Revision as of 16:25, 10 December 2010

Warning: This is only true starting with FusionForge 5.1. Previous versions have a slightly more reduced system.

The permissions in FusionForge are managed along the role-based access control (RBAC) model. In short, individual users don't have permissions, but they have a set of roles, and each role has a set of permissions. When a user tries to accomplish an action that's restricted, the available roles are checked; if one of the roles has the required permisson, the action can go on. If none of the roles available to the user at that time have the permission, the action is denied.

The RBAC model used here is an extension of what was used up until FusionForge 5.0, designed as part of the Coclico project and more formally documented on Planetforge.org.


The roles can be described according to how they're defined:

  • Explicit roles are simple enumerations of users. When a user is logged in, the available roles include all the roles the user is a member of.
  • Implicit roles are defined functionnally. FusionForge includes two such roles: the LoggedIn role is available everytime a session is open (which can be used to grant some rights to people with an account on the forge); the Anonymous role is always available, whether logged in or not (so it can be used to allow some actions even for non-authenticated users). Note that the permissions acquired via the Anonymous role are not lost when a session is opened: both roles are active, as well as any roles the user might have otherwise.

Roles can also be described according to their scope:

  • Project roles are roles created within a project. They can typically include a role for developers, a role for project managers, a role for trainees, a role for tech support, and so on. As soon as a user is assigned one (or more) role(s) in a project, they're considered as a member of the project.
  • Global roles are roles not attached to a project in particular, but forge-wide. Along with the LoggedIn and Anonymous roles (which are global), a typical forge will have a Forge admin role, and a News admin role. These two last roles will be configured to have the appropriate permissions for administering the forge and approving the news for the front page, respectively.

Project roles and global roles can be "shared", which allows referencing them in 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.


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.