Hello Belén, While I agree with your assessment in general, there is one possible problem I foresee: If I understand it right, in the distributed approach anyone can create a new project whenever they want to. While this shouldn't be a problem under normal working conditions for a small to medium user base, I feel that for a public implementation or a very large user base this might present a resource problem in that, due to a large number of active projects, queues might grow to become far too large for normal use. By extension, I think this might also be a vulnerability for malicious users to exploit.
If I might suggest a hybrid of the two approaches, as follows: 3. The Hybrid Basically, this is a distributed approach, with an additional layer on top - a moderately powerful administrator that grants project-creation rights to users, as needed. This way I feel we maintain most of the benefits of the distributed approach, as opposed to the top-down approach, but with the added security of not allowing just anyone who gets access to the toaster server to create a project and request resources without some supervision, be it from the "administrator" that granted them project creation rights or the project owner that granted them access to their project. Of course, I just might be overly paranoid :) I hope my description was clear both regarding my concerns and the proposed implementation. Cheers, Mihail -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Barros Pena, Belen Sent: Friday, October 24, 2014 6:38 PM To: [email protected] Subject: [Toaster] [RFC] Toaster access control One of the new features we are supposed to deliver in Toaster 1.8 is access control: i.e. the concept of users and permissions. This is the Bugzilla entry for the design https://bugzilla.yoctoproject.org/show_bug.cgi?id=6233 I think there are basically 2 approaches we can take for access control: 1. Top-down approach 2. Distributed approach 1. The top-down approach This is the approach where there is an all powerful administrator that creates users, grants them permissions and administers them. The all powerful administrator is the access gatekeeper. If you want to use Toaster you need to request access somehow. The all powerful administrator will (or will not) grant you access, and will decide what you can and cannot do in Toaster. This is a very common approach: Bugzilla works like this. Moderated mailing lists work essentially like this. I believe Jenkins works like this too. 2. Distributed approach User management is a shared responsibility between all users who can create Toaster projects. Users are invited to join a particular project by the project creator. Project creators decide what the people they invite can do within that project and within Toaster. This is the approach used by the Basecamp project management tool (https://basecamp.com/). 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. Thanks! Belén -- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster -- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
