You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@continuum.apache.org by Carlos Sanchez <ca...@apache.org> on 2006/07/11 00:41:25 UTC
Continuum Security design
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.
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: Continuum Security design
Posted by Carlos Sanchez <ca...@apache.org>.
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 <je...@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
Re: Continuum Security design
Posted by Jesse McConnell <je...@gmail.com>.
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
Posted by Joakim Erdfelt <jo...@mergere.com>.
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] <jerdfelt> jmcconnell: do you see the comment in it's fully
rendered splendor?
[11:02:21] <jmcconnell> jerdfelt: yep, much better :)
[11:03:28] <jmcconnell> jerdfelt: and I agree totally, that my thought
as well
[11:04:37] <jmcconnell> only question is if the roles should be provided
globally or on a per project basis
[11:04:57] <jerdfelt> per project.
[11:05:07] <jerdfelt> but when you add the 'group' wrinkle, things get odd.
[11:05:12] <jmcconnell> ya
[11:05:53] <jmcconnell> when you kick this up a lvl it gets messy
[11:06:22] <jmcconnell> kinda like groups should be a part of projects
[11:07:16] <jmcconnell> and you can maintain one user having access to
multiple projects and being a member of different groups in different
projects
[11:08:28] <jmcconnell> suppose the thing to do is respond to that mail
[11:08:31] <jerdfelt> jmcconnell: yes, the ability to belong to multiple
groups is needed.
[11:08:54] <jmcconnell> multiple groups in a projects or multiple
projects/one group each
[11:09:21] <jerdfelt> ah, the many to many, many to one, one to many
question.
[11:09:35] <jerdfelt> Each group needs to support multiple projects.
[11:09:43] <jmcconnell> if we get to that point then we ought to toss
the group concept and go straight to project roles
[11:09:57] <jmcconnell> with profiles that can be applied topeople to
easily manage the roles they have
[11:10:09] <jerdfelt> ah. profiles. good idea.
[11:10:26] <jerdfelt> cept, we could call them groups to the users. ;-)
[11:10:29] <jmcconnell> the groups concept doesn't scale with this
[11:10:55] <jmcconnell> right, but the group membership does nothing
except toggle the appropriate roles
[11:11:24] <jerdfelt> question is, should the profile be enforced?
[11:11:48] <jmcconnell> and when rendering we check if their role config
matchs any known 'groups' and if not then render as 'custom'
[11:11:49] <jerdfelt> or is it just the ability to set a large set of
permissions on a one time basis.
[11:12:12] <jmcconnell> the latter
[11:12:24] <jmcconnell> makes it easier to setup a user's roles
[11:12:26] <jerdfelt> we could create virtual users that are actually
groups. map them to a user via a role. (ick)
[11:13:35] <jmcconnell> 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] <jerdfelt> is there an upper limit on role names?
[11:13:57] <jerdfelt> i want it to be a simple role check at the code
level.
[11:14:07] <jmcconnell> jerdfelt: exactly
[11:14:20] <jmcconnell> manageing the users role is just a UI issue at
that point
[11:14:29] <jmcconnell> unless we have this group concept in place as well
[11:14:36] <jerdfelt> wonder if I should just copy/paste this IRC
discussion into the continuum-dev list. ;-)
[11:14:55] <jmcconnell> which kinda seems like an unholy marriage of
security strategies
[11:15:00] <jerdfelt> I see the group concept as needed from a user
point of view.
[11:15:01] <jmcconnell> jerdfelt: yes, we should
- Joakim Erdfelt
Re: Continuum Security design
Posted by Jesse McConnell <je...@gmail.com>.
carlos,
how would you recommend we implement the
users/groups/roles/permissions material that we have already been
discussing?
would it be implementing the rbac model using the
AccessDecisionManager and AccessDecisionVoter dealio in acegi? I can
see how we might go about doing it in acegi, it would be a matter of
figuring out how to map the rbac data into GrantingAuthorities that
would be setup during the authentication, and then figuring out how
that pans out in the authorization side of things...
what are your thoughts on getting the rbac aspect of authorization
working with acegi?
jesse
On 7/26/06, Carlos Sanchez <ca...@apache.org> wrote:
> I think is more important now come with a good representation of
> users, groups, roles,... that can be used across all apps (Continuum,
> MRM,...)
>
> Acegi doesn't mess with your code, so the need of another api on top
> of it for me has no much sense.
>
> I like the aop approach better than implementing interfaces for the
> same reason, it doesn't get in your way. You can secure anything
> pretty easily. I have made some progress on this but other things
> needed my attention, I'll have the integration bits ready soon.
>
> On 7/26/06, Jesse McConnell <je...@gmail.com> wrote:
> > I have been working on a little security api in the plexus sandbox
> > that I wanted to describe to the continuum dev list that would work
> > for the implementation of the authentication and authorization parts
> > of continuum.
> >
> > I like it since it is pretty easy to use and should extend to support
> > the zones ideas we have been describing in some of these discussions
> > on irc and on this mailing list.
> >
> > Basically its an object called a PlexusSecurityRealm that is
> > configured in the components.xml to have an AuthenticationStore and an
> > AuthorizationStore. These stores have one method each called
> > authenticate( tokenMap ) and authorize( session, tokenMap ). The PSR
> > has some convience methods for working with these so you can call
> > things like isAuthentic( tokens ) or isAuthorized( session, tokens ).
> >
> > I made a simple implementation of both stores and then an acegi
> > authentication store as well so far. The acegi authentication store
> > is nice in that it is also all configured in the components.xml file
> > and can link up to whatever acegi can for authentication purposes.
> >
> > Now the authorization side of the fence is a little more murky. I am
> > really trying to seperate out the authentication process,
> > authorization process and the gathering if user details and stuff.
> > Acegi implementation really binds the authentication and authorization
> > concepts together which makes it difficult to wrap them up as distinct
> > seperate components. I have an Object in that AuthenticationResult
> > object that is returned from the authentication store where we can
> > shove the acegi authentication object and the authorization store can
> > make use of that.
> >
> > I think the real big decision that needs to be made in regards to
> > continuum and authentication/authorization is how implementation
> > specific do we want to go?
> >
> > Acegi has a whole host of fun little bells and whistles but they are
> > peppered all through your code or are injected in the flow of things
> > through web filters and the like. This lets you do fun little things
> > like secure all the user management code behind a particular url, say
> > **/users/*, with a particular role or something. It provides some
> > taglibs for optionally rendering page content based on roles. It also
> > has a pretty strong aop integration that lets you manage security of
> > objects in your codebase without actually modifying any of your code.
> >
> > My thinking on the matter was more along the lines of letting whatever
> > object in the system, be it webwork rendering, data objects, or flow
> > control to be able to have one object that they could ask isAuthentic(
> > X ) and/or isAuthorized( X ) and react accordingly and let all the
> > howto mumbo jumbo be configured in other components. Plexus would
> > basically manage all the nuts and bolts of what to authenticate to and
> > authorize on and the application code would just ask the questions
> > itself. This has the benefit of readability but probably isn't as
> > nimble an idea as the aop bits of acegi.
> >
> > does anyone have any feelings one way or the other on this?
> >
> > jesse
> >
> >
> > On 7/19/06, Jesse McConnell <je...@gmail.com> wrote:
> > > There was some discussion on irc about the security model so I wrote
> > > up this description for review by everyone.
> > >
> > > http://docs.codehaus.org/display/CONTINUUM/Straight+Role+Based+Access+Control
> > >
> > > It doesn't have implementation details in it, it is just an attempt at
> > > drawing together the different concepts we have been talking about
> > > together so we can agree on 'what we want' and then we can focus on
> > > 'how to do it'.
> > >
> > > personally, I think this basic idea could go into plexus (if it isn't
> > > already there with jason's rbac stuff) pretty smoothly and then have
> > > different implementations like carlo's acegi stuff...
> > >
> > > but anyway, please review the above and comment
> > >
> > > cheers!
> > >
> > > jesse
> > >
> > > On 7/18/06, Brett Porter <br...@apache.org> wrote:
> > > > I've added my comments.
> > > >
> > > > I don't think we need domain ACLs - it's an interesting concept but it
> > > > also worries me a little to have security as an afterthought - it's
> > > > intrinsic to the design of the code in some ways (surely if you only
> > > > want to give one person access to a subset of the data you also want to
> > > > avoid going ahead and retrieving the data in the first place). Perhaps I
> > > > misunderstand it's intent.
> > > >
> > > > So, where are we at with this? I don't think its healthy to keep a
> > > > branch for too long on something so fundamental as it'll become hard to
> > > > merge back in, but is Acegi proving to be both non-intrusive and capable
> > > > of doing what we need? What state is it in?
> > > >
> > > > - Brett
> > > >
> > > > On 11/07/2006 8:41 AM, 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.
> > > > >
> > > >
> > > >
> > > > --
> > > > Apache Maven - http://maven.apache.org/
> > > > Better Builds with Maven - http://library.mergere.com/
> > > >
> > >
> > >
> > > --
> > > jesse mcconnell
> > > jesse.mcconnell@gmail.com
> > >
> >
> >
> > --
> > jesse mcconnell
> > jesse.mcconnell@gmail.com
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
--
jesse mcconnell
jesse.mcconnell@gmail.com
Re: Continuum Security design
Posted by Carlos Sanchez <ca...@apache.org>.
I think is more important now come with a good representation of
users, groups, roles,... that can be used across all apps (Continuum,
MRM,...)
Acegi doesn't mess with your code, so the need of another api on top
of it for me has no much sense.
I like the aop approach better than implementing interfaces for the
same reason, it doesn't get in your way. You can secure anything
pretty easily. I have made some progress on this but other things
needed my attention, I'll have the integration bits ready soon.
On 7/26/06, Jesse McConnell <je...@gmail.com> wrote:
> I have been working on a little security api in the plexus sandbox
> that I wanted to describe to the continuum dev list that would work
> for the implementation of the authentication and authorization parts
> of continuum.
>
> I like it since it is pretty easy to use and should extend to support
> the zones ideas we have been describing in some of these discussions
> on irc and on this mailing list.
>
> Basically its an object called a PlexusSecurityRealm that is
> configured in the components.xml to have an AuthenticationStore and an
> AuthorizationStore. These stores have one method each called
> authenticate( tokenMap ) and authorize( session, tokenMap ). The PSR
> has some convience methods for working with these so you can call
> things like isAuthentic( tokens ) or isAuthorized( session, tokens ).
>
> I made a simple implementation of both stores and then an acegi
> authentication store as well so far. The acegi authentication store
> is nice in that it is also all configured in the components.xml file
> and can link up to whatever acegi can for authentication purposes.
>
> Now the authorization side of the fence is a little more murky. I am
> really trying to seperate out the authentication process,
> authorization process and the gathering if user details and stuff.
> Acegi implementation really binds the authentication and authorization
> concepts together which makes it difficult to wrap them up as distinct
> seperate components. I have an Object in that AuthenticationResult
> object that is returned from the authentication store where we can
> shove the acegi authentication object and the authorization store can
> make use of that.
>
> I think the real big decision that needs to be made in regards to
> continuum and authentication/authorization is how implementation
> specific do we want to go?
>
> Acegi has a whole host of fun little bells and whistles but they are
> peppered all through your code or are injected in the flow of things
> through web filters and the like. This lets you do fun little things
> like secure all the user management code behind a particular url, say
> **/users/*, with a particular role or something. It provides some
> taglibs for optionally rendering page content based on roles. It also
> has a pretty strong aop integration that lets you manage security of
> objects in your codebase without actually modifying any of your code.
>
> My thinking on the matter was more along the lines of letting whatever
> object in the system, be it webwork rendering, data objects, or flow
> control to be able to have one object that they could ask isAuthentic(
> X ) and/or isAuthorized( X ) and react accordingly and let all the
> howto mumbo jumbo be configured in other components. Plexus would
> basically manage all the nuts and bolts of what to authenticate to and
> authorize on and the application code would just ask the questions
> itself. This has the benefit of readability but probably isn't as
> nimble an idea as the aop bits of acegi.
>
> does anyone have any feelings one way or the other on this?
>
> jesse
>
>
> On 7/19/06, Jesse McConnell <je...@gmail.com> wrote:
> > There was some discussion on irc about the security model so I wrote
> > up this description for review by everyone.
> >
> > http://docs.codehaus.org/display/CONTINUUM/Straight+Role+Based+Access+Control
> >
> > It doesn't have implementation details in it, it is just an attempt at
> > drawing together the different concepts we have been talking about
> > together so we can agree on 'what we want' and then we can focus on
> > 'how to do it'.
> >
> > personally, I think this basic idea could go into plexus (if it isn't
> > already there with jason's rbac stuff) pretty smoothly and then have
> > different implementations like carlo's acegi stuff...
> >
> > but anyway, please review the above and comment
> >
> > cheers!
> >
> > jesse
> >
> > On 7/18/06, Brett Porter <br...@apache.org> wrote:
> > > I've added my comments.
> > >
> > > I don't think we need domain ACLs - it's an interesting concept but it
> > > also worries me a little to have security as an afterthought - it's
> > > intrinsic to the design of the code in some ways (surely if you only
> > > want to give one person access to a subset of the data you also want to
> > > avoid going ahead and retrieving the data in the first place). Perhaps I
> > > misunderstand it's intent.
> > >
> > > So, where are we at with this? I don't think its healthy to keep a
> > > branch for too long on something so fundamental as it'll become hard to
> > > merge back in, but is Acegi proving to be both non-intrusive and capable
> > > of doing what we need? What state is it in?
> > >
> > > - Brett
> > >
> > > On 11/07/2006 8:41 AM, 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.
> > > >
> > >
> > >
> > > --
> > > Apache Maven - http://maven.apache.org/
> > > Better Builds with Maven - http://library.mergere.com/
> > >
> >
> >
> > --
> > jesse mcconnell
> > jesse.mcconnell@gmail.com
> >
>
>
> --
> jesse mcconnell
> jesse.mcconnell@gmail.com
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: Continuum Security design
Posted by Jesse McConnell <je...@gmail.com>.
I have been working on a little security api in the plexus sandbox
that I wanted to describe to the continuum dev list that would work
for the implementation of the authentication and authorization parts
of continuum.
I like it since it is pretty easy to use and should extend to support
the zones ideas we have been describing in some of these discussions
on irc and on this mailing list.
Basically its an object called a PlexusSecurityRealm that is
configured in the components.xml to have an AuthenticationStore and an
AuthorizationStore. These stores have one method each called
authenticate( tokenMap ) and authorize( session, tokenMap ). The PSR
has some convience methods for working with these so you can call
things like isAuthentic( tokens ) or isAuthorized( session, tokens ).
I made a simple implementation of both stores and then an acegi
authentication store as well so far. The acegi authentication store
is nice in that it is also all configured in the components.xml file
and can link up to whatever acegi can for authentication purposes.
Now the authorization side of the fence is a little more murky. I am
really trying to seperate out the authentication process,
authorization process and the gathering if user details and stuff.
Acegi implementation really binds the authentication and authorization
concepts together which makes it difficult to wrap them up as distinct
seperate components. I have an Object in that AuthenticationResult
object that is returned from the authentication store where we can
shove the acegi authentication object and the authorization store can
make use of that.
I think the real big decision that needs to be made in regards to
continuum and authentication/authorization is how implementation
specific do we want to go?
Acegi has a whole host of fun little bells and whistles but they are
peppered all through your code or are injected in the flow of things
through web filters and the like. This lets you do fun little things
like secure all the user management code behind a particular url, say
**/users/*, with a particular role or something. It provides some
taglibs for optionally rendering page content based on roles. It also
has a pretty strong aop integration that lets you manage security of
objects in your codebase without actually modifying any of your code.
My thinking on the matter was more along the lines of letting whatever
object in the system, be it webwork rendering, data objects, or flow
control to be able to have one object that they could ask isAuthentic(
X ) and/or isAuthorized( X ) and react accordingly and let all the
howto mumbo jumbo be configured in other components. Plexus would
basically manage all the nuts and bolts of what to authenticate to and
authorize on and the application code would just ask the questions
itself. This has the benefit of readability but probably isn't as
nimble an idea as the aop bits of acegi.
does anyone have any feelings one way or the other on this?
jesse
On 7/19/06, Jesse McConnell <je...@gmail.com> wrote:
> There was some discussion on irc about the security model so I wrote
> up this description for review by everyone.
>
> http://docs.codehaus.org/display/CONTINUUM/Straight+Role+Based+Access+Control
>
> It doesn't have implementation details in it, it is just an attempt at
> drawing together the different concepts we have been talking about
> together so we can agree on 'what we want' and then we can focus on
> 'how to do it'.
>
> personally, I think this basic idea could go into plexus (if it isn't
> already there with jason's rbac stuff) pretty smoothly and then have
> different implementations like carlo's acegi stuff...
>
> but anyway, please review the above and comment
>
> cheers!
>
> jesse
>
> On 7/18/06, Brett Porter <br...@apache.org> wrote:
> > I've added my comments.
> >
> > I don't think we need domain ACLs - it's an interesting concept but it
> > also worries me a little to have security as an afterthought - it's
> > intrinsic to the design of the code in some ways (surely if you only
> > want to give one person access to a subset of the data you also want to
> > avoid going ahead and retrieving the data in the first place). Perhaps I
> > misunderstand it's intent.
> >
> > So, where are we at with this? I don't think its healthy to keep a
> > branch for too long on something so fundamental as it'll become hard to
> > merge back in, but is Acegi proving to be both non-intrusive and capable
> > of doing what we need? What state is it in?
> >
> > - Brett
> >
> > On 11/07/2006 8:41 AM, 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.
> > >
> >
> >
> > --
> > Apache Maven - http://maven.apache.org/
> > Better Builds with Maven - http://library.mergere.com/
> >
>
>
> --
> jesse mcconnell
> jesse.mcconnell@gmail.com
>
--
jesse mcconnell
jesse.mcconnell@gmail.com
Re: Continuum Security design
Posted by Jesse McConnell <je...@gmail.com>.
There was some discussion on irc about the security model so I wrote
up this description for review by everyone.
http://docs.codehaus.org/display/CONTINUUM/Straight+Role+Based+Access+Control
It doesn't have implementation details in it, it is just an attempt at
drawing together the different concepts we have been talking about
together so we can agree on 'what we want' and then we can focus on
'how to do it'.
personally, I think this basic idea could go into plexus (if it isn't
already there with jason's rbac stuff) pretty smoothly and then have
different implementations like carlo's acegi stuff...
but anyway, please review the above and comment
cheers!
jesse
On 7/18/06, Brett Porter <br...@apache.org> wrote:
> I've added my comments.
>
> I don't think we need domain ACLs - it's an interesting concept but it
> also worries me a little to have security as an afterthought - it's
> intrinsic to the design of the code in some ways (surely if you only
> want to give one person access to a subset of the data you also want to
> avoid going ahead and retrieving the data in the first place). Perhaps I
> misunderstand it's intent.
>
> So, where are we at with this? I don't think its healthy to keep a
> branch for too long on something so fundamental as it'll become hard to
> merge back in, but is Acegi proving to be both non-intrusive and capable
> of doing what we need? What state is it in?
>
> - Brett
>
> On 11/07/2006 8:41 AM, 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.
> >
>
>
> --
> Apache Maven - http://maven.apache.org/
> Better Builds with Maven - http://library.mergere.com/
>
--
jesse mcconnell
jesse.mcconnell@gmail.com
Re: Continuum Security design
Posted by Brett Porter <br...@apache.org>.
I've added my comments.
I don't think we need domain ACLs - it's an interesting concept but it
also worries me a little to have security as an afterthought - it's
intrinsic to the design of the code in some ways (surely if you only
want to give one person access to a subset of the data you also want to
avoid going ahead and retrieving the data in the first place). Perhaps I
misunderstand it's intent.
So, where are we at with this? I don't think its healthy to keep a
branch for too long on something so fundamental as it'll become hard to
merge back in, but is Acegi proving to be both non-intrusive and capable
of doing what we need? What state is it in?
- Brett
On 11/07/2006 8:41 AM, 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.
>
--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
Re: Continuum Security design
Posted by Joakim Erdfelt <jo...@erdfelt.com>.
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] <jerdfelt> jmcconnell: do you see the comment in it's fully
rendered splendor?
[11:02:21] <jmcconnell> jerdfelt: yep, much better :)
[11:03:28] <jmcconnell> jerdfelt: and I agree totally, that my thought
as well
[11:04:37] <jmcconnell> only question is if the roles should be provided
globally or on a per project basis
[11:04:57] <jerdfelt> per project.
[11:05:07] <jerdfelt> but when you add the 'group' wrinkle, things get odd.
[11:05:12] <jmcconnell> ya
[11:05:53] <jmcconnell> when you kick this up a lvl it gets messy
[11:06:22] <jmcconnell> kinda like groups should be a part of projects
[11:07:16] <jmcconnell> and you can maintain one user having access to
multiple projects and being a member of different groups in different
projects
[11:08:28] <jmcconnell> suppose the thing to do is respond to that mail
[11:08:31] <jerdfelt> jmcconnell: yes, the ability to belong to multiple
groups is needed.
[11:08:54] <jmcconnell> multiple groups in a projects or multiple
projects/one group each
[11:09:21] <jerdfelt> ah, the many to many, many to one, one to many
question.
[11:09:35] <jerdfelt> Each group needs to support multiple projects.
[11:09:43] <jmcconnell> if we get to that point then we ought to toss
the group concept and go straight to project roles
[11:09:57] <jmcconnell> with profiles that can be applied topeople to
easily manage the roles they have
[11:10:09] <jerdfelt> ah. profiles. good idea.
[11:10:26] <jerdfelt> cept, we could call them groups to the users. ;-)
[11:10:29] <jmcconnell> the groups concept doesn't scale with this
[11:10:55] <jmcconnell> right, but the group membership does nothing
except toggle the appropriate roles
[11:11:24] <jerdfelt> question is, should the profile be enforced?
[11:11:48] <jmcconnell> and when rendering we check if their role config
matchs any known 'groups' and if not then render as 'custom'
[11:11:49] <jerdfelt> or is it just the ability to set a large set of
permissions on a one time basis.
[11:12:12] <jmcconnell> the latter
[11:12:24] <jmcconnell> makes it easier to setup a user's roles
[11:12:26] <jerdfelt> we could create virtual users that are actually
groups. map them to a user via a role. (ick)
[11:13:35] <jmcconnell> 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] <jerdfelt> is there an upper limit on role names?
[11:13:57] <jerdfelt> i want it to be a simple role check at the code level.
[11:14:07] <jmcconnell> jerdfelt: exactly
[11:14:20] <jmcconnell> manageing the users role is just a UI issue at
that point
[11:14:29] <jmcconnell> unless we have this group concept in place as well
[11:14:36] <jerdfelt> wonder if I should just copy/paste this IRC
discussion into the continuum-dev list. ;-)
[11:14:55] <jmcconnell> which kinda seems like an unholy marriage of
security strategies
[11:15:00] <jerdfelt> I see the group concept as needed from a user
point of view.
[11:15:01] <jmcconnell> jerdfelt: yes, we should
- Joakim Erdfelt