[Zope-dev] LOTS of roles?

Oliver Bleutgen myzope@gmx.net
Tue, 25 Feb 2003 11:50:54 +0100


Paul Winkler wrote:
> On Mon, Feb 24, 2003 at 12:41:01PM +0100, Oliver Bleutgen wrote:

>>Since your application might not be suited for that scheme, it might be 
>>worth throwing out roles altogether. How about creating a role for each 
>>user (i.e. user "user_id" get's just the role "user_id", instead of 
>>creating a role for for each possible (task,location) tuple.
>>When creating a new user, the admin would have to just assign the 
>>permissions, instead of roles. This task could be made easier by 
>>creating template permission sets.
> 
> 
> Interesting idea... tell me if I'm wrong, but I see two obvious
> problems with this approach:
>     
> 1)  for one-role-per-user:  we'd have to visit the security management for
> N objects in Zope and adjust the permissions every time we add a user.
> Whereas in my proposal, we only need to do that every time we add
> a site or change the tasks, which happens much less frequently.  
> 
> 2) for one-role-per-user, changing a user's privileges means wanding around
> the ZMI setting permissions on N objects.
> Whereas in my scheme, we can do that in one place (LDAP) by 
> adding or removing a role or two.
> 
> 
>>You might wind up with less roles and I bet administration is a lot easier.
> 
> 
> my guess is that in our case, the number of roles would be comparable.
> 200 sites * 10 tasks = 2000 roles
> 200 sites * 10 users = 2000 roles
> 

I think I still don't get all the characteristics of you application. So 
I'll try to post what I had in mind:

- implement a kind of permission matrix: "tasks"x"sites",i.e. permission 
1X says that the user who has this permission is allowed to call 
taskX(site=1,...). Then in taskX you could check if the user has the 
permission 1X, and otherwise throw an exception.

- write an UI which hides the existance of roles, instead let the admin 
assign permissions directly to users (by implictly creating one role 
named user_id with all the permissions the admin choose). Optionally 
give the admin some knobs to use "permission templates" or other 
helpers. Note that this could still be combined with "normal" roles for 
everything which has nothing to do with your "sites".

So I don't see why your point 1) and 2) could be an issue, unless you 
also need stuff like local roles for other things etc. - but that seems 
to be solvable through an UI too.

Then you'd have sites*tasks permissions, and as many roles as you have 
users. And maybe you steered around the complexity problem w.r.t roles too.

cheers,
oliver