[Zope3-dev] Permission granularity/permission groups

[Jim Fulton]

Roger Ineichen wrote:
> Hi
> 
> 
>>-----Original Message-----
>>From: zope3-dev-bounces+dev=projekt01.ch at zope.org 
>>[mailto:zope3-dev-bounces+dev=projekt01.ch at zope.org] On 
>>Behalf Of Jim Fulton
>>Sent: Wednesday, February 09, 2005 6:40 PM
>>To: Garrett Smith
>>Cc: zope3-dev (E-mail)
>>Subject: Re: [Zope3-dev] Permission granularity/permission groups
>>
>>Garrett Smith wrote:
>>
>>>As I define the permissions for my application, two things 
>>
>>strike me:
>>
>>>- I'm wanting to group permissions -- e.g. 'manage content' 
>>
>>might be a
>>
>>>permission that also includes 'add content', 'modify content', and
>>>'delete content'.
>>>
>>>- Because permission grouping is yet another complexity layer, I'm
>>>thinking that creating fine level permissions is better 
>>
>>than generalized
>>
>>>permissions (i.e. scrap 'manage' in favor of separate 
>>
>>'add', 'modify',
>>
>>>and 'delete') -- I can then get permission groups using roles.
>>>
>>>So my questions:
>>>
>>>1 - Do people generally agree that permission groups is 
>>
>>unneeded because
>>
>>>the same effect can be accomplished using roles (and 
>>
>>perhaps otherwise
>>
>>>bad for complexity/performance reasons).
>>
>>Assuming that you don't let users grant permission sto roles, then
>>I think that roles is an acceptable short-term alternative to 
>>permission
>>groups.  I don't have time to implement permission groups 
>>anytime soon.
>>
>>Someday, I'd like to use roles for something a little different than
>>permission groups, but I don't know if I'll every get around to that.
>>
>>
>>>2 - When defining permissions for an application, is it 
>>
>>better to start
>>
>>>with fine level permissions -- i.e. try to get everything 
>>
>>right from the
>>
>>>start? Or is there a good strategy to start with more general
>>>permissions and migrate an app later as needs require?
>>
>>I'm inclined to think starting general is better.
>>
>>
>>>My concern in question 2 is that I'm not sure what permissions are
>>>'correct' and would prefer to start at a high level and 
>>
>>move to finer
>>
>>>level permissions over time.
>>
>>Right
>>
>> > But won't this imply complicated upgrade
>>
>>>scripts over time?
>>
>>Only if you let users grant to permissions directly.
>>
>>Give the current permissions+roles scheme, I'd like
>>to remove permissions from the current granting UI.
>>(This would make a much better UI possible, BTW.)
>>
>>If user's can only grant to roles, then all you need
>>to do when you change permissions is to adjust the
>>role-permission map as necessary.
> 
> 
> A permission group or role is the same, it's just 
> the name that doesn't fit?

In theory, they are different.  In practice,
as currently implemented, a role is just a group
of permissions.

> Both a role or a permision group are contained or mapped to
> principals and declare which permission they have.
> 
> Or I'm wrong?

I would word it differently.

- Roles can be granted to users

- Permissions can be grantd to users

- Permissions can be granted to roles

You can think of this as "mapping", but I prefer the
term grant.  Actually, if we were using roles as "roles",
rather than permission groups, I would say that roles are
assigned to users. Theoretically, roles are "jobs" or positions
people have relative to the system.

> If I understand you correct, we shouldn't map permissions
> to principals directly for a better separation and future
> migrations.

IMO, the granting of permissions to roles should be hidden from
users. I would treat this as software configuration.  That's
why I moved this UI to ++etc++site a few months ago.

IMO, users should not be allowed to grant permissions to users.
Disallowing this would:

- Allow us to change role-permission assignments centrally, and

- would simplify and allow a much better granting interface.

An even better alternative, if someone was so inspired, would
be for someone to make a new security policy from the
current one by changing the word "role" to something else
(e.g. "privilege") throughout. (There would probably be some
other minor word changes.) This would be a purely mechanical
change -- still a fair bit of work.  We could make this new
security policy  the default.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org