Common CMS roles and access levels

Question

I am currently writing a CMS and remember someone (it might have been on here) criticise the existing CMS for not having a robust enough user permissions system. I\'ve got a me

Answer 1

Have you researched existing solutions like RBAC? Whilst such a system would most likely be complete overkill for the particular nut you're trying to crack it would at least help to boost confidence that you're on the right track.

That aside, the general roles I'd expect would be along the lines of:

Administator - Total control of the system, can view logs (as you should be logging all changes), etc. plus...

Publisher - Can put content live plus...

Author - Can create content

However, how these roles are applied across the system is where things get tricky, as a specific user would presumably have different rights to different content areas/modules.

Answer 2

This is the "best practice" I have ended up with in most projects and am very happy with:

1. Roles

When it comes to roles, I recommend great flexibility, i.e. the ability to create and define user accounts and groups freely (roles like "contributor", "manager" etc. are not hard-coded, but put into a configuration file that can be changed per application). The role configuration is unaccessible to the user, but the engine itself should be free from hard-coded roles.

2. Rights

Rights is where things need to be easy to understand and implement.

I have made very good experiences working with, and checking against, very fine-grained rights on the code / API level:

• see
• view
• edit
• change name
• rename
• delete
• move
• change rights
• etc.

but the user never sees those. For them, they are grouped into a very small number of "right groups":

• Read Only
• Edit
• Administer = Move, rename....

The user never sees the "move" right, but only the "Administer" rights group.

That way, you retain the full power of fine-grained rights in your code for the future - you can, for example, easily accommodate for a rule like "interns must be able to edit pages, but not be able to change their titles, nor to delete them", adding a valuable asset to the CMS. For the end user, this functionality remains invisible, and the rights system easy to use.

Answer 3

For most applications, so I think it'll be true for CMSs as well, my customers usually prefer a rights-oriented approach. Here is how it goes :

1. You list the main actions. In your CMS that would be : Create and edit content; Delete content; Classify/categorize content; Validate content; Publish content; Manage users; Etc.
2. You define what actions are allowed or denied for each user

To make things a little better, you can create several roles (Editor; Administrator) to make typical users creation easier (by pre-filling the form when a role is chosen).