Re: Continuum Security design
Carlos Sanchez wrote: http://docs.codehaus.org/display/CONTINUUM/Security Please take a look and provide feedback on the semantics of what to secure and to what level. Some discussion with Jesse McConnell about the security ... [11:01:38] jmcconnell: do you see the comment in it's fully rendered splendor? [11:02:21] jerdfelt: yep, much better :) [11:03:28] jerdfelt: and I agree totally, that my thought as well [11:04:37] only question is if the roles should be provided globally or on a per project basis [11:04:57] per project. [11:05:07] but when you add the 'group' wrinkle, things get odd. [11:05:12] ya [11:05:53] when you kick this up a lvl it gets messy [11:06:22] kinda like groups should be a part of projects [11:07:16] and you can maintain one user having access to multiple projects and being a member of different groups in different projects [11:08:28] suppose the thing to do is respond to that mail [11:08:31] jmcconnell: yes, the ability to belong to multiple groups is needed. [11:08:54] multiple groups in a projects or multiple projects/one group each [11:09:21] ah, the many to many, many to one, one to many question. [11:09:35] Each group needs to support multiple projects. [11:09:43] if we get to that point then we ought to toss the group concept and go straight to project roles [11:09:57] with profiles that can be applied topeople to easily manage the roles they have [11:10:09] ah. profiles. good idea. [11:10:26] cept, we could call them groups to the users. ;-) [11:10:29] the groups concept doesn't scale with this [11:10:55] right, but the group membership does nothing except toggle the appropriate roles [11:11:24] question is, should the profile be enforced? [11:11:48] and when rendering we check if their role config matchs any known 'groups' and if not then render as 'custom' [11:11:49] or is it just the ability to set a large set of permissions on a one time basis. [11:12:12] the latter [11:12:24] makes it easier to setup a user's roles [11:12:26] we could create virtual users that are actually groups. map them to a user via a role. (ick) [11:13:35] well, if this is the way to go then its simply a matter of how best to manage all the possibloe rolls across all the projects...when it comes to a particular security check it is a simple role check and that is it [11:13:37] is there an upper limit on role names? [11:13:57] i want it to be a simple role check at the code level. [11:14:07] jerdfelt: exactly [11:14:20] manageing the users role is just a UI issue at that point [11:14:29] unless we have this group concept in place as well [11:14:36] wonder if I should just copy/paste this IRC discussion into the continuum-dev list. ;-) [11:14:55] which kinda seems like an unholy marriage of security strategies [11:15:00] I see the group concept as needed from a user point of view. [11:15:01] jerdfelt: yes, we should - Joakim Erdfelt
Re: Continuum Security design
I've updated the wiki with my latest thoughts. I suggest this reading http://acegisecurity.org/docbook/acegi.html#domain-acls which explains how to add instance based security with ACLs. It's a good option and allows fine grained permissions for user, project and type of operation. On 7/11/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: well, here are my thoughts on the matter summed up after some subsequent discussion on this between joakim, carlos and myself: If continuum is to scale up to multiple projects, say continuum building in the same instance along side maven and the maven repository manager then we are going to need a simple fine grained security mechanism that isn't clunky to use. the perhaps ill chosen 'unholy marriage of security strategies' phrase above basically refers to the current implementation of groups and roles. We have role based security for all of the different types functionalities, and then it has been kicked around to have group based access to different projects...and these groups are made up of sets of roles. Perhaps there was some misunderstanding on the specifics but at least my thoughts on the matter are that we are best served with a straight forward role based security model where access to special views and the ability to perform certain actions are governed by individual roles on a per project basis. ie, if there is a role for 'FORCE_BUILDS' then there ought to be one of these roles for each project in continuum, in the above example we might have 'CONTINUUM_FORCE_BUILD', MAVEN_FORCE_BUILD' and 'MRM_FORCE_BUILD'. Each user would have the ability to be assigned these roles and would then have that access for each of the particular projects. If we have this simple role based approach then all of the security checks, which as joakim mentioned are the vast majority of usage for the security', are very simple role checks. It becomes then a matter of figuring out the best way to manage these roles and there are lots of different examples of that out in the wild, be they the ability to make profiles of roles that can be applied to users, to long lists of checkboxes (not so fun). Joakim had mentioned that the roles would likely be dynamic based on the projects as they were added in and that we could put in some simple dynamic filters or profiles that would initialize the project and a user with the necessary settings and then further access could be pushed out from there.. I talked to trygve about this a bit and he mentioned that jason has put some rbac (http://en.wikipedia.org/wiki/RBAC) code into plexus sometime ago...and that is ultimately where any of this needs to end up so that other projects can have immediate access to the different security mechanisms. carlos, joakim...I miss anything in this? -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Continuum Security design
well, here are my thoughts on the matter summed up after some subsequent discussion on this between joakim, carlos and myself: If continuum is to scale up to multiple projects, say continuum building in the same instance along side maven and the maven repository manager then we are going to need a simple fine grained security mechanism that isn't clunky to use. the perhaps ill chosen 'unholy marriage of security strategies' phrase above basically refers to the current implementation of groups and roles. We have role based security for all of the different types functionalities, and then it has been kicked around to have group based access to different projects...and these groups are made up of sets of roles. Perhaps there was some misunderstanding on the specifics but at least my thoughts on the matter are that we are best served with a straight forward role based security model where access to special views and the ability to perform certain actions are governed by individual roles on a per project basis. ie, if there is a role for 'FORCE_BUILDS' then there ought to be one of these roles for each project in continuum, in the above example we might have 'CONTINUUM_FORCE_BUILD', MAVEN_FORCE_BUILD' and 'MRM_FORCE_BUILD'. Each user would have the ability to be assigned these roles and would then have that access for each of the particular projects. If we have this simple role based approach then all of the security checks, which as joakim mentioned are the vast majority of usage for the security', are very simple role checks. It becomes then a matter of figuring out the best way to manage these roles and there are lots of different examples of that out in the wild, be they the ability to make profiles of roles that can be applied to users, to long lists of checkboxes (not so fun). Joakim had mentioned that the roles would likely be dynamic based on the projects as they were added in and that we could put in some simple dynamic filters or profiles that would initialize the project and a user with the necessary settings and then further access could be pushed out from there.. I talked to trygve about this a bit and he mentioned that jason has put some rbac (http://en.wikipedia.org/wiki/RBAC) code into plexus sometime ago...and that is ultimately where any of this needs to end up so that other projects can have immediate access to the different security mechanisms. carlos, joakim...I miss anything in this?
Re: Continuum Security design
Carlos Sanchez wrote: http://docs.codehaus.org/display/CONTINUUM/Security Please take a look and provide feedback on the semantics of what to secure and to what level. Some discussion with Jesse McConnell about the security ... [11:01:38] jmcconnell: do you see the comment in it's fully rendered splendor? [11:02:21] jerdfelt: yep, much better :) [11:03:28] jerdfelt: and I agree totally, that my thought as well [11:04:37] only question is if the roles should be provided globally or on a per project basis [11:04:57] per project. [11:05:07] but when you add the 'group' wrinkle, things get odd. [11:05:12] ya [11:05:53] when you kick this up a lvl it gets messy [11:06:22] kinda like groups should be a part of projects [11:07:16] and you can maintain one user having access to multiple projects and being a member of different groups in different projects [11:08:28] suppose the thing to do is respond to that mail [11:08:31] jmcconnell: yes, the ability to belong to multiple groups is needed. [11:08:54] multiple groups in a projects or multiple projects/one group each [11:09:21] ah, the many to many, many to one, one to many question. [11:09:35] Each group needs to support multiple projects. [11:09:43] if we get to that point then we ought to toss the group concept and go straight to project roles [11:09:57] with profiles that can be applied topeople to easily manage the roles they have [11:10:09] ah. profiles. good idea. [11:10:26] cept, we could call them groups to the users. ;-) [11:10:29] the groups concept doesn't scale with this [11:10:55] right, but the group membership does nothing except toggle the appropriate roles [11:11:24] question is, should the profile be enforced? [11:11:48] and when rendering we check if their role config matchs any known 'groups' and if not then render as 'custom' [11:11:49] or is it just the ability to set a large set of permissions on a one time basis. [11:12:12] the latter [11:12:24] makes it easier to setup a user's roles [11:12:26] we could create virtual users that are actually groups. map them to a user via a role. (ick) [11:13:35] well, if this is the way to go then its simply a matter of how best to manage all the possibloe rolls across all the projects...when it comes to a particular security check it is a simple role check and that is it [11:13:37] is there an upper limit on role names? [11:13:57] i want it to be a simple role check at the code level. [11:14:07] jerdfelt: exactly [11:14:20] manageing the users role is just a UI issue at that point [11:14:29] unless we have this group concept in place as well [11:14:36] wonder if I should just copy/paste this IRC discussion into the continuum-dev list. ;-) [11:14:55] which kinda seems like an unholy marriage of security strategies [11:15:00] I see the group concept as needed from a user point of view. [11:15:01] jerdfelt: yes, we should - Joakim Erdfelt
