continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlos Sanchez" <car...@apache.org>
Subject Re: Continuum Security design
Date Tue, 11 Jul 2006 20:26:50 GMT
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 <jesse.mcconnell@gmail.com> 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

Mime
View raw message