Identity: Attaching permissions directly to users (Ticket #505)

[Jeff Watkins]

Since this seems to come up occasionally, I'm sharing my response to
this ticket with the entire TG community. I'm certain at least one
person will tell me "that's the stupidest thing I've ever heard"...

----
> hi, i recently start to play with the identity frameworks from
> turbogears and i really dont get the point of linking permission to
> groups. if the 'write' permission is linked against the 'admin'
> group, all users in admin group have write permission. if i need
> diferente parmission for a specific user, i need to create another
> group. so, what is the point? i really think that 'permissions'
> should be linked against 'users'. this way the 'group' should say
> which objects u can access and permission what u can do with given
> objects.
There is nothing preventing you from creating a Model that better
suits your needs, however, experience with large user communities
shows that you're almost always better off modelling via Users-
>Groups<-Permissions rather than applying permissions directly to a
particular User.

If for no other reason, provisioning new users becomes a huge
problem. Consider the following example:

Sally, the nurse retires and her replacement Sam needs to be
provisioned in the new system. In an environment where permissions
are applied via groups, Sam is made a member of the Nurse group and
he immediately acquires *every* applicable permission. If permissions
are applied directly to the user, you need to explicitly apply every
permission in order to provision Sam.

Six months later, you role out new functionality for nurses. This new
functionality includes new permissions -- all nurses should have
these permissions. If you've modelled your users using groups, you
add the permissions to the nurses group and immediately every nurse,
including Sam, can now access the new functionality. If you haven't
modelled your data using groups, you need to add the permissions to
every single nurse. Now ask yourself, if you don't have groups, how
do you know who all the nurses are?

Now if you have a VERY small user community, applying permissions
directly to the user isn't a bad model. And I run into this a lot
with clients. Mostly when I encounter this model it's after they've
grown from a small number of users to many hundreds or even
thousands. In these cases, the permissions are often controlled by
different application specialists and no one quite knows what the
definitive set of permissions actually is for a given group or role.

--
Jeff Watkins
http://newburyportion.com/

"Just because you have the right to do something, doesn't mean it's
the right thing to do."
-- Fred Friendly, former president of CBS News

[Jorge Godoy]

Jeff Watkins <je...@newburyportion.com> writes:

> Now if you have a VERY small user community, applying permissions directly to
> the user isn't a bad model. And I run into this a lot with clients. Mostly
> when I encounter this model it's after they've grown from a small number of
> users to many hundreds or even thousands. In these cases, the permissions are
> often controlled by different application specialists and no one quite knows
> what the definitive set of permissions actually is for a given group or role.

I prefer using groups even for small ammounts of users. One can, then, create
one group per user if it is needed. When groups of users need one common
permission, then a new group can be created and users can be assigned to it.
I find that this -- one user/groups and several users/group with permissions
dealt with by group -- are the best approach.

--
Jorge Godoy <jgo...@gmail.com>

[Alberto Valverde]

> Since this seems to come up occasionally, I'm sharing my response
> to this ticket with the entire TG community. I'm certain at least
> one person will tell me "that's the stupidest thing I've ever
> heard"...

Doesn't sound stupid at all :)

On Feb 5, 2006, at 4:19 PM, Jeff Watkins wrote:

> There is nothing preventing you from creating a Model that better
> suits your needs, however, experience with large user communities
> shows that you're almost always better off modelling via Users-
> >Groups<-Permissions rather than applying permissions directly to a
> particular User.

It's essential for user management (when there are more, than let's
say 10 users :). As you pointed out.

I have a little "semantic" quirk though:

I have subclassed for one of my apps a small variation of TGs default
identity scheme in which I substitute TG_Group for Role (as It fits
better in my head: "Permissions tied to Roles"), for example,
GROUP_ADMIN (which has permissions "can create user", "can edit
user", etc...). Then it have a different Group class (which isn't the
same concept as TG_Group) which models different groups in wihch
users are "grouped" into as to limit the scope in which a GROUP_ADMIN
has priviileges on, for example. These Groups have no permissions
attached to them whatsoever, theyre just to relate users among
themselves.

Just wanted to share it with you.

Regards, Alberto

[Neil Tiffin]

Using Users->Groups<-Permissions is definitely better for any system
with more than 100 users. I inherited a system (over 100 users)
where permissions were managed directly to users. It was very easy
and quick to fix/modify one Users permissions. However, we never
could find the time to rationalize the overall permissions as most
users with the same job requirements had over time evolved different
permissions. Why? We never knew for sure although we ended up
spending considerable time for each change trying to resolve
differences.

Using Users->Groups<-Permissions forces one to spend more time up-
front keeping permissions rationalized. Rational permissions may or
may not be important in a given installation. I agree with Jeff that
it should be the heavily favored option. It can be used for small
user communities without a lot of additional overhead (just a little
thinking beforehand). So I don't really see a downside.

Neil