continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joakim Erdfelt <>
Subject Re: Continuum Security design
Date Tue, 11 Jul 2006 15:22:10 GMT
Carlos Sanchez wrote:
> 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 
[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 
[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

View raw message