CMS Permissions Model

Can anyone describe an efficient and semi-simple way of applying a whole series of permissions (view,read,post,edit,delete,etc.) that can be applied to multiple content components and allows moderators, administrators, etc. to override user-based permissions? I know I've basically asked the same question before, but I was able to get that system to work to my satisfaction at the time. Now I want something that is scalable to multiple components and isn't session based, meaning the implementation doesn't require custom sessions.

My setup involves users and groups that both could potentially have mutually exclusive permissions (a user belonging to a group could have permission to do one thing, but since he is a member of the group, he can't and vice-versa). The permission system I've devised works until I try to figure out a clean way of allowing moderators and administrators a way of overriding the user and group permissions. I think I'm almost there, I just need someone to point out a trick to doing this right. Any help would be greatly appreciated.

By "overriding," do you mean changing permissions, or just having the permissions not apply to them? (or both? :))

The latter would be the case in my statement... that moderators should be able to do things such as edit and delete even though their own user-level permissions deny them this ability and no other group-level permission allow them to do so. However, having the variable option of changing others' permissions would definitely be part of an ideal system; I don't think that would be as difficult to implement though.

How does your implementation work right now? (if it's not too hard to explain.. :))

The current implementation requires the user to be checked for every post no matter what, thereby either creating a large amount of overhead or giving the users the ability to edit their own posts even if their permissions deny them that right. I know this isn't an excellent description of the system, however I'm looking more for how it's done professionally than what little thing is wrong with my novice work (although I guess I could somehow be considered a professional now that I have my degree :p).

Quote:

---

Originally posted by Nephalim
The current implementation requires the user to be checked for every post no matter what,

---

Ah.. so that's what you meant by not being session based? :)

Quote:

---

thereby either creating a large amount of overhead or giving the users the ability to edit their own posts even if their permissions deny them that right.

---

You're saying that would happen if you didn't check the permissions every time, right?

Quote:

---

I know this isn't an excellent description of the system, however I'm looking more for how it's done professionally than what little thing is wrong with my novice work (although I guess I could somehow be considered a professional now that I have my degree :p).

---

Yeah that's what I figured, since I didn't really know what you were talking about. :D

Optimizations, though, really depend on the exactly how your system is used. I could suggest one way of doing what I think you want to do, but it would be horribly slow in certain circumstances. :) You are basically asking for an optimized implementation, right?

I've implemented a subtractive permissions model in few different versions of a CMS in the past. Much like anything, there are certainly more than one way to skin a cat here...but I'm not sure what advice or direction I can give you based on the information you've provided here.

Give us a detailed overview of your current permissions model. Database schema, use-cases, etc would be helpful if you really want some solid advice on optimizations.

Re: Strogian quote #1
No, not being custom session based means that the permissions are not part of a custom sessions package that keeps track of not only regular session data, but also user and entity information regarding permissions. This is the way that most of the few online examples have done it... i'm trying to make each component (permissions, sessions, error handling, etc.) separate but interfaceable instead.

Re: Strogian quote #2
Correct.

Et Al.
I could only force myself to do use-cases if my job were dependent upon it. ;) Yeck!

Right now my CMS is set up much like this forum. There are categories that contain several topics that, in turn, contain multiple posts. In the future I plan to add a news service, a wish list service, and multiple other components that will all be tied into the same user/group permissions system.

So, for the way things are now, there are five tables involved in the permissions makeup: user, groups, category, user_groups (forming the many-to-many between user and groups), and category_permissions (forming the many-to-many between groups and category). From there, three sets of permissions exist: one for the user (read,post,edit,etc.), one for the category (same), and one for the group (same, but in the category_permissions table).

At the time that any category is accessed, all the permissions are compared (using the tertiary(?) statement) for user and category and then overwritten by the group permissions. However, because the edit and delete permissions should only be granted to the user who posted it and to the moderators, those permissions are forced to off. Lastly, the author of the post is compared with the current user and given permission to edit and delete their own posts regardless of whether or not the category or group permissions deny them that. This is what I'm trying to avoid. It's all a big ugly mess.

Subtractive permissions model?

Yeah it's starting to get rather messy, or so it sounds :) First things first - "subtractive permissions", google it and you'll find this among many other explanations.

It's a popular method of enforcing permissions on resources. In short, a user has 3 possible access-states for a given resource. Granted, denied, or not specified. In the case that a user is a member of 2+ groups, and has his/her own permissions defined as well, the heirarchy of how these access-states are derived becomes extreemly important. If a user is a member of 12 groups that all grant him/her the access rights to the "wash car" resource, but his/her local user-permissions deny him/her access to the "wash car" resource, he/she should have a "denied" access-state to that resource. Or in simplier terms, 1 "no" overrides 12 "yes's".

Currently, I'm a little unclear on how you're applying group permissions. You said users and groups have a many-to-many relationship, so how are you currently handling a user who is a member of 2+ groups? How are permissions applied when one group says "yes", and one group says "no" ?

So far I've neglected to mention how to handle the "not specified" state. When a given user or group is not specifically granted, or denied access to a resource, you need a default access-state. In most cases you want the default access-state set to "deny", but it really depends on the application or system you're working with. If you're only going to deny 5% of the resource requests on average, than it doesn't really make sense to default access-states to "deny", because if you did, you would have to grant 95% of the resource requests through an explicit "grant" flag somewhere in the database. Instead, it would make more sense to have a default access-state of "grant", and then you would only have to have "deny" flags explicitly defined for 5% of the requests.

I'm starting to feel like I'm rambling on here...but my hope is to be helpful here, so let me know if anything above seems unclear, I know I can be a little whacky with my wording sometimes.

It sounds like you only have one level of "categories" in your data model. Does your system eventually need to be able to apply permissions recursively, on an infinite hierarchy of resources? Or in other words, you probably want to design your permissions module to be able to handle categories within categories (within categories, within categories, etc etc).

The last CMS I worked on did just that, and I'll admit it was no easy trick for me. It was my first real dive into the world of permissions modeling, but it was a lot of fun. One of the super-key concepts I had to tackle was object abstraction. Your application sounds like it will someday have a lot of different types of resources that you want to apply permissions on. In some cases it's categories, topics, posts, etc that need to be abstracted so they can all be thought of as a common type of thing you can apply permissions on. I like calling them all "resources" but you can call them what you like. This way, all you need to do is register each object that you want to apply permissions on as a "resource" with the system, so you can then have a simplifed set of permissions algorithms that enforce permissions on resources in a uniform manner.

The same applies to users, and groups. I believe I ended up abstracting those as "actors" in my data model. That way, my permissions module only had to worry about defining, and enforcing permissions between "resources" and "actors", and didn't have to worry about the potentially infinite different types of resources and actors that existed. Abstraction is key to any good data model, but I think it's crucial to any truly scalable permissions model.

People write books the size of war & peace on this topic - and my knowlege of it is limited at best. It's a massive topic...and I really can't do it justice on a public message board. Hopefully I've provided enough info to point you in the right direction, but if you want to chat more about this sometime, I'd be happy to help. PM me with some ICQ, or AIM info if you want and we can chat in more detail sometime.

Yes, yes, yes... I like the sound of all that, even if it was long-winded! :D :cool: I'll read up on it ASAP. Perhaps you could explain the resources and actors entities to me just a little bit more, though. Do you basically register resource_id, resource_type (as in category) and fill in the permissions? The same for actors? That sounds suspicously plausible.

I've searched all over for any information on permissions systems of any sort, subtractive or not. I haven't found much. The most I've found is in regards to an open source project called OpenACS. OpenACS has detailed documentation of its permissions API and the data model it was created with. I'm reading over the material now, but i think I'll be pulling on my hair over this one for quite some time to come.

Yeah - like I said it's a massively extensive subject, and it can also be equally complex. When I started developing a CMS for the company I work for, I scoured the web trying to read as much as I could on permissions modeling before diving in myself. I basically found the same stuff you've probably read, and felt the same way you do about right now.

Most of the documentation I found was based on some custom J2EE applications, and a few generic operating system permission models / theory as well. My impression was that much of the research & development in this field is probably considered valuable intellectual property to most companies out there. Either that or most companies and organizations aren't willing to spend the tremendous amount of time that would be necessary to publish concise, yet information html documentation on the fruits of their research.

In the end I figured out a lot of things on my own after a few iterations of the code and data model. The fourth version (version = complete scrap of code, rebuilt from ground up each time) finally started to take some formation that was to my liking. Unfortunately I got moved to some new projects since then, but I hope to return to it within the year. I think another 4 or 5 versions and I might have something worth shaking a stick at.

Ultimately, I know I'm re-inventing the wheel since countless other code-monkeys and corporations out there have made some type of CMS or another, but at the very least I think it's a healthy excercise for the serious programmer or data modeler.

I don't know if you're familiar with Python or not, but one of the best CMS's I've ever seen is Zope. It has a rather impressive security framework, among other things.

You don't have to know Python to understand the design concepts behind Zope. They appear to have some fairly decent documentation, so you might want to poke around there for a while if you're still in research-mode.

Again, best of luck Neph. Have fun with it.