Web applications and other multi-user systems need to authenticate users. When users are authenticated they have access to selected resources - in some systems access is granted to everything but in most systems access in only granted to selected stuff.
Let's discuss two methods to distinguish user privileges in multi-user systems.
The access the users have might (maybe should) influence the functions they are presented - as changes in the UI, specifically menus eg. - and of course the data that can be accessed.
Layered approach
Layers of access in a good way to arrange user access. With layered access roles can be arranged in such a way the switching roles upwards give access to more data and functions in the UI. A system might have these roles:
- Collaborator
- User
- Project manager
- Administrator
In a layered system a collaborator could be an external resource that is brought in to weigh in on a specific part of a project. A user will be a person that have access to certain tasks/projects/files etc.. The project manager role will let the user see projects along with the stuff the users with the user role are working on. A user with the administrator role will have full access to all projects and all the data in the system.
When privileges are layered it might be easier to resolve exactly what the users can access and what functions to user should be exposed to. When roles are assigned to users it somewhat easy to identify and verify what it has been done properly and what the user should be able to access.
Single permissions
Another way to think about user privileges is to have single permissions that is more or less directly linked to data access and (UI) functions for the user.
This will give a more flexible permission system and will allow functions to available to some users and not to others.
With the roles from the previous example in mind we can imagine the users and project managers having functions that the administrators aren't interrested in or need to have access to. Another way to think about this is that something like the front page in the system needs to present information very differently to collaborators and administrators. These can be isolated in a way that these are actually separate features that is only accessible for users with the corresponding permission.
Comparison
When using the layered model it is easy to manage in data. It is essentially one field user.role - and the value of this is changed as the user role changed. Adding new roles is no big deal - it just needs to be implemented in the system and the data model is ready for it. The biggest pain is when deciding where in the layered privilege system to put the new user role - from the stuff the user should access it should be very clear - but the desires/requirements might put you in a situation where you are whishing for a single permission privilige system.
That might be the solution but it also comes with it's own problems. Adding new permissions will add complexity to the data stored. It could even lead to changes in the data model. The single permissions will make up a permission matrix and if a permission is added it is essentially a change in the matrix dimensions.
When designing systems with user privileges you need to think long and hard about how you want to design the authentication system and your approuch to privilige management.