Re: [RFC] Toaster access control

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2014-10-24 at 15:37 +0000, Barros Pena, Belen wrote:
> How both approaches compare?
> 
> * In the top-down approach, the fundamental unit for user management is a
> Toaster instance; in the distributed approach, the fundamental unit for
> user management is a Toaster project.
> 
> * The top-down approach requires a central place for user management that
> can only be accessed by the all powerful administrator(s). This central
> place is outside and above Toaster projects. In the distributed approach,
> user management takes place within a Toaster project.
> 
> * In the top-down approach, the user management task falls on the all
> powerful administrator(s). In the distributed approach, user management is
> shared between all project creators.
> 
> * The top-down approach is request-based: I must solicit access to Toaster
> to the all powerful administrator, who then decides which projects I can
> access and what I can do in Toaster. The distributed approach is
> invitation-based: the project creator invites me to access her project.
> 
> * In the top-down approach, there is normally one all powerful
> administrator and then a whole bunch of Toaster users. In the distributed
> approach, there are a whole bunch of project creators and a whole bunch of
> project users.
> 
> Which approach do I like best? The distributed one, of course. This is why:
> 
> 1. Because so far we have designed Toaster to be project based. For
> example, although there is a global layer list in the Toaster database
> that spans all projects, layers are only exposed in the context of a
> certain project. There are no Toaster pages outside of projects, apart
> from the landing page. The distributed approach to access control reflects
> this currently existing structure, which keeps things nice and simple.
> 
> 2. Because it avoids the need for a global administration interface. There
> are Toaster projects, and within a project you have a list of the people
> who have access to that project.
> 
> 3. Because it shares the responsibility of user management: no single
> person has to deal with this very annoying task. The responsibility is
> shared between all project creators.
> 
> 4. Because it makes user management easier: no need to deal with a list of
> a million users, and give each of them access to 50 projects. User lists
> are broken down by project, which means shorter lists. Project access
> granting happens organically, instead of in a single go. Inviting existing
> users to a project is easy because we keep a global list of users that
> spans all projects, even if we choose not to show it: typing a name should
> provide you suggestions from existing users, and you can select one of
> them or create a new one as needed.
> 
> 5. Because it avoids the need for sophisticated user management features,
> such as Active Directory integration (don't laugh:
> https://wiki.jenkins-ci.org/display/JENKINS/Active+Directory+plugin),
> which we are in no position to deliver.
> 
> But I am just the designer: what the hell do I know? So it would be good
> to find out which approach you prefer and why.

I think this is fine, however there is a "but" coming. I believe there
will be some "site" configuration which people will desire, for example
whether users can or cannot invite other users to projects or can create
new users. Some of these operations will need to be restricted to some
set of users.

So whilst I like the idea, there will be a pressure towards elements of
the other model and there are some reasons for that which we should try
and consider if we can.

I feel I'm explaining that badly, I hope this is understandable...

Cheers,

Richard