[Fusionforge-general] [Discussions] RFC: Convergence on access control model?

christian bac christian.bac at it-sudparis.eu
Thu Apr 8 10:23:39 CEST 2010


Just a full forward to the coclico wp1 and some remarks, whishes, at the
end.

On Fri, 2010-04-02 at 10:40 +0200, Roland Mas wrote: 
> Hi all,
> 
>   I'm currently working on improving the FusionForge role-based access
> control system (RBAC).  My immediate goal is to allow the RBAC code to
> control permissions it doesn't know about in advance, for instance
> because these are defined by a plugin.  In concrete terms, the Evolvis
> guys (hi!) want to be able to control the Mediawiki permissions through
> the forge's RBAC (and related web UI) rather than through editing of
> configuration files.  I have a prototype that seems to work for the
> common cases, but completing that is going to require some reworking of
> the RBAC system.
> 
>   Also, as part of the Coclico project, there is interest in convergence
> of the models, because that will allow the Mediawiki plugin for
> FusionForge to also work on Codendi.  By a happy coincidence, there was
> a Coclico meeting yesterday, so I took the opportunity to discuss the
> matter with the Codendi guys.  As a result, I refined my ideas, and I'd
> like to submit them here for discussion.  I believe the model is going
> to be:
> - at least as capable as FusionForge's current RBAC;
> - at least as capable as Codendi's current "ugroups" system;
> - simpler to understand;
> - simpler to code;
> - more extensible for plugins.
> 
>   Here's my proposed model.  I'd appreciate any comments :-)
> 
> Current system in FusionForge
> -----------------------------
>   FusionForge has a role concept (and class).  A role is linked to a
> project, and serves as the link between a project and its members: each
> member belongs to the project according to exactly one role.
> 
>   Each role has a number of settings.  A role setting encodes the
> permissions that role has on a specific tool (for instance,
> post/read/none on a forum).  There are (theoretically) as many settings
> in a role as there are tools linked to that role's project.  If a
> project has three trackers, each of the roles for this project will have
> three independent settings.
> 
>   The actual permission system is simple: when a user tries to do an
> action on a tool in a project, the forge looks up the setting
> corresponding to the specific tool for the user's role in the project.
> If the setting says the action is allowed, then it can go forward,
> otherwise permission denied.
> 
>   There are two quirks though.
> 
>   First, what happens when the currently logged-in user is not a member
> of the project?  Or if the person browsing the web interface isn't even
> logged in?  Well in that case, the forge uses a different object, called
> RoleObserver.  Although that class has a similar name, and there is some
> code in common with Role, it behaves rather differently.  In particular,
> the settings are quite different.  Broadly, instead of controlling write
> permissions, they focus on read permissions, with a specific twist: even
> though the same RoleObserver is used for non-members and non-logged-in
> visitors, there is a setting differenciating the permissions according
> to session status, which allows blocking anonymous forum postings by
> passing visitors without an account.  Besides, even though it's
> presented in a UI similar to the one used for roles, the settings are
> actually not stored in anything like a role_observer_setting table, but
> directly in a column in the tools' tables.  For instance, the public's
> visibility on a particular tracker is stored in the "public" column of
> the "artifact_group_list" table.
> 
>   Second quirk, some permissions are not linked to a project in
> particular.  Things like forge-wide administration (approving project
> submissions, news for the front page, user management, and so on) are
> instead controlled by membership in special projects (siteadmin and
> newsadmin, for instance).
> 
>   Drawbacks of this system: no real differenciation of
> anonymous/non-members, no ability to delegate permissions to plugins for
> the RoleObserver stuff, an ugly model for site-wide administrative
> privileges, and so on.
> 
> Current system in Codendi
> -------------------------
>   (This is based on memory, *please* correct me if I'm wrong)
> 
>   My understanding is that GForge replaced the per-user permission
> system with RBAC *after* Codendi started, and that per-user system was
> extended in Codendi rather than replaced, although there is something
> that smells a bit like RBAC in some cases.  The system is called
> "ugroups" (for "user groups").
> 
>   Ugroups are, basically, lists of users.  They can be local to a
> project or global, so a project can define its own list of developers,
> and the forge admin can define a company-wide QA team, for instance.
> Ugroups can also have implicit membership rather than explicit; in other
> words, some ugroups members that are not *listed* but *computed*.  For
> instance, an ugroup can be defined as the union of two other ugroups, so
> you can have an ugroup for all developers in a project (ie, all members
> who are either in the "junior dev" or the "senior dev" ugroup).  There's
> another implicit ugroup for "all the members of this project".  There's
> one for "anonymous visitor".  And so on.  It follows that users can
> belong to more than one ugroup.
> 
>   Most of the permissions can be assigned to ugroups (in the same way as
> they are assigned to roles in FusionForge).  There are, however, some
> permissions that remain linked to individual users (in the same way as
> the pre-Codendi GForge), with an explicit matrix of users
> vs. permissions filled with allowed/denied bits.
> 
>   Drawbacks of this system (again, this is my understanding and it can
> be flawed): not all permission bits are managed the same way (ugroups
> vs. explicit matrix), and the matrix itself is a bit unwieldy for large
> projects.
> 
> A comparison
> ------------
>   The two systems aren't that different, actually.  The common case is
> rather similar: user -> role/ugroup -> permissions.  The most notable
> differences are:
> - RBAC in FusionForge controls all permissions on projects' tools (no
> individual user/tool matrix);
> - Codendi allows several ugroups for the same user;
> - implicit ugroups in Codendi don't exist in FusionForge;
> - the case of "anonymous" is handled by a ugroup in Codendi, by a
> special role in FusionForge.
> 
>   (Also differences in implementation, obviously, but I'm focusing on
> the model here)
> 
> My proposal
> -----------
>   Based on the comparison above, and the drawbacks mentioned, here's
> what I think could work.  Hopefully, it's “RBAC done right, this time”.
> The high-level view:
> 
> - We keep the notion of role/ugroup.  I'll call it role because I'm more
> used to the term (and also because "anonymous" is more a position than a
> list of users), but the wording isn't very important.
> 
> - A role is linked to 0 or 1 project, so as to keep the possibility of a
> "company-wide QA team" role.
> 
> - We also keep the notion of functionally defined roles (with implicit
> membership).  This gives us "anonymous", "forge user", "all members of
> this project", "members of at least one project", and so on.
> 
> - Users belong to a project according to at least one role, possibly
> more.  In addition, they may also have one or more global roles (the
> "all registered users" role being the obvious start).
> 
> - All permissions become role-based.  No more permission bits stored in
> tools' tables (especially since some tools may not even have tables of
> their own, think of the version control system for instance).
> 
> - A "setting" belongs to one role only, and expresses access to
> something.  That something can identified with a (section,id) pair; for
> instance, (tracker,123) or (forum,456).  The access is an integer whose
> semantics can vary according to the tool: one could imagine a bit-field
> for complex stuff (think of the admin/tech/both/none system in trackers)
> or an access level if that matters (eg. post/read-only/none for forums).
> 
> - An authorization decision is based on the settings of all available
> roles.  If a user is logged in, then the access control must list all
> roles the user has (including implicit ones), and check if at least one
> of them has the required permission.  If so, then the access is granted
> and the requested action can proceed; if not, permission denied.  When
> there's no session open (anonymous visitor), the set of available roles
> only includes the "anonymous" role, but the decision-making process is
> unchanged.
> 
>   I think this gives us a superset of the existing semantics, so that
> both FusionForge and Codendi will be able to "upgrade" to the new model
> without loss of functionality.  From what I remember of the time when
> GForge migrated from user-based to role-based, the users were surprised
> by the change, but they adopted it quite fast; I'm confident the Codendi
> users will do the same.
> 
>   I also have a few ideas about implementation, but they are likely to
> change based on comments about the proposed model, so I'll keep them for
> another email.  For now, let's see some discussion :-)
> 
> Roland.

To help integrating other tools with plugins, I would appreciate some
mechanism helping the forge to discover the roles in the external
tool : 
- for example when integrating a wiki, being able to find that the
rights management are related to pages and you can have the classical
Create Read Update Delete rights on one page (URI).
- also some specific rights like super admin or admin to create one
space associated to a managed group.

I'm not sure that this should be understandable by the forge code
itself, but rather by the users. So that the forge can propose roles and
rights to a user for an external tool and relay the information to that
tool so that the tool is able to set up its protections accordingly.

I think roland will not agree on the assumption that each tool is
responsible of its rights management, but in my point of view it helps
in integrating tools that are very differents.

C.Bac





More information about the Fusionforge-general mailing list