User and Group Permissions in a CMS

Posted At : February 21, 2007 3:03 PM
Related Categories: Web Dev

When creating permissions for objects within a system one often finds themselves stuck in a situation where multiple matches can occur.

Take for example an editable object in a CMS. One can assign users to this object and give them specific rights. In this case lets say "edit, display, publish, and history". Lets also say that the user also has some default rights regarding how their editor profile should be loaded such as which buttons to see, what style sheet to use, etc.

Now, lets also say that groups can be assigned to that object, and that of course users can be allocated to those groups.

The tricky part is to figure out what is most logical to administrators and end users in how you determine those rights.

For example, lets say there are two groups and a user assigned to the "hot news" content object.

Group A: Edit, Display, History Group B: Edit, Display

User A: Display

IF User A is about to use the object the only ability they have is "display" at this point.

What happens if they also belong to Group B? Should Group B abilities take over or should User A specific profile apply?

In my case I opted for Users always having more weight than a group. In other words when assigning that user to the group you specifically said yes to display and NO to all other abilities. So in all cases that profile should take precedence regardless of the Group rights which may apply to that user.

Now in the next scenario we have:

Group A: Display, History Group B: Edit, Display

User A is assigned to BOTH groups and has no specific assignment to the object.

When User A visits that object what abilities should they have? There are different ways to approach this. You could say that you take the first group that applies, the last, or merge the groups together. In this case I opted to take the granted abilities of all groups found for that object that the user belongs to. I then merge those abilities together.

So User A, by belonging to both groups, has Display, Edit and History available.

The inverse of that could have been applied instead. One could have taken only matches between the groups as the final right given. In that case User A would only have Display rights because those are the only rights that match as a true value between the two groups that the user belongs to.

Right now I am defaulting to matching all positives for groups, but I may change this to be configurable by the admin of the CMS so they can determine if they want to go positive or negative.

Any other directions to take?

Comments (7) |

Print |

del.icio.us |

Digg It! | 1878 Views

TweetBacks

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)

[Add Comment] [Subscribe to Comments]

Hi Joshua,

Interesting post - I need to be thinking about this some time in the next few days for an updated permissioning system for LightBase.

By default I was thinking of a summing process so in the first case user would have had their permissions and their associated group permissions, but then there is no easy way to handle "negative" permissions as you pointed out.

The most accurate solution would be to explicitly document positives and negatives separately, so if you wanted to keep a user from editing but have all of the other group permissions, you'd create a block (lets call it) to stop that user from editing that object type. That would be the most flexible approach, but immediately I'm worried about UI and training issues. That said, anyone who is creating a user role to achieve the intent in your first case (negative permissions) is somewhat of an advanced user, and I can see a lot of room for error with implicit blocks like you are suggesting. Lets say you want to promote a user with one extra privilege - how would that work? You'd have to replicate all of the permissions of all of their groups which would not be a good thing.

I'm not sure about UI and training, but I'm still tempted by explicitly allowing both positive and negative permissions (say permissions and blocks) with the blocks being available via an advanced tab so as not to confuse the majority of users - or perhaps via a "add block" link or something . . .

# Posted By Peter Bell | 2/21/07 4:04 PM

Why can't you write about things I understand? I'm just a girl, you know.

# Posted By Liberty | 2/21/07 4:11 PM

@ Peter

The reason I have User a higher wieght is to allow for negative permissions actually. So a Sports Coach group may have rights to a bunch of pages, but then a user assigned to the sports coach group could be explicitly assigned to an object and set to NO for all permission options, thus having no rights even though the rest of the group does.

The way I have set it up permission is only NULL if a user or group isn't assigned.

Null is only meaningfull at this point to determine to use a User profile or Group profile (or site wide at some point).

If a user is assigned or a group then it is always explicitly yes or no for each option. In other words for our settings for edit there is a YES and NO radio option. So it would always be explicit. You can add a user and that user could have explicitly set NO to all options, which would then overwrite any group settings that relate to that user.

I think we got the UI down pretty well and it is pretty intuitive for our users so far, though adding groups to the mix certainly compounds the confusion for some I would think. IE you can have different options for one object on the same page than another object.

@ Liberty

Girls kick ass.

# Posted By Joshua Cyr | 2/21/07 4:29 PM

Hi Joshua,

I suppose the most flexible approach would still be to have two settings for any given permission: allow and deny. That would mean you could do fun things like create sub groups with inheritance trees and could definitively set allows and denys at any level (so a group could be denied a specific permission as well as a user). That said, I can see that it might be confusing . . .

# Posted By Peter Bell | 2/21/07 5:04 PM

Interesting path. I use to lead the development team of a competing CMS and we chose to use what we called net rights. I found that, for our users, at least, it was easier to comprehend that we would simply take the highest set of permissions on an object.

If an object required admin permissions to, say, delete that object then a user who was either assigned that privilege explicitly or belonged to a group that had that right could delete the object. Highest perm-level wins, in our case. We spent enough time dissecting permissions issues without having to deal with the added complexity of an intricate algorithm. :-)

# Posted By Rob Wilkerson | 3/23/07 7:56 AM

Hi Rob,

We thought about that approach, but I wanted a way for the user admin to be able to explicitly deny rights to a user as well, sort of as an override of sitewide permissions. So far the code and functionality is working well, and we are just now rolling it out to customers, so we will see how intuitive it is to them. Crossing my fingers. ;-)

# Posted By Joshua Cyr | 3/26/07 12:45 PM

Good luck. If I were a religious man, my prayers would be with your support team. Since I'm not, though, my prayers would be of no use whatsoever. :-)

# Posted By Rob Wilkerson | 3/26/07 12:49 PM

[Add Comment]