How to give rights to a System Administrator in an application?

Question

I am designing a security model for a web application which restricts access to certain parts of the app depending on what rights and permissions the user has. These rights and permissions are grouped together into Roles that each user can be assigned to.

However I need to create an System Administrator role that gives a special user full access to everything. In order to tackle this I can go about it in two ways:

1. Create a Role of System Administrator and give it every single permission/right in the system (basically all the rights are stored in a DB table). As the application evolves and becomes larger, the Administrator role must also be updated so that it has access to the new stuff.
2. Within the application itself, I allow for the System Administrator role to bypass security restrictions. So essentially it will check if the user has a certain permission, or if they're a System Administrator, it will let them through.

Option 1 presents some problems: it could be tedious and prone to oversight because each area of the application has Create, Read, Update, Write, and many more permissions. I have to include every possible combination of application area to permissions in a table for the role to have full access.

Option 2 present its own problems: the System Administrator bypass is hard-coded into every single area where a restriction is needed. If the name of the System Administrator role was to change (e.g. Master User) then I'd have to update the code everywhere. However this option means I don't need to worry about constantly updating the Role table so that the System Administrator gets permission to access new stuff.

I'm building an enterprise class software so it has to be scalable whichever option I go with.

Yes I know this is highly subjective if just treated just as is. But I believe there must be some good-practice security design pattern where one way is recommended over the other. There are things I can't foresee right now which others may have encountered. I would even appreciate some links to thoughts on this and good way to go forward.

Answer 1

How about you factor out authorization to a single function that makes all security decisions. Calls would be something like isAccessAllowed(user, FOO_OPERATION, <misc data>). Then your admin check is a single conditional in the start of the isAccessAllowed function.

Implementing such a system also allows you to change security backends without having to rewrite your application. It also does a nice job of separating security code from application code.

Answer 2

I think both the two options are a good way to go. However, I think you consider this problem the wrong side. The two drawbacks you quoted for you two problems can be easily overcome :

1. For the first option : if you consider giving all the rights to the Systems Administrator role and are afraid about the combinations, then I'm guessing you can just sorta double test with two loops, e.g. (pseudo-mushy-code inside) : if($role == "Administrator") { for($i in $rights_array) { $area[$i] = true; }}

I know this code is pretty ridiculous for the moment but it explains very well what I try to say : you don't have to manually implement every single possible combination (area, rights). Once your areas and rights are separately defined in your database, you can set your combination values dynamically in variables.

If you really want to store your "rights combinations" in a database, you can also handle this automatically the same way as with the pseudo-code I gave earlier. I already coded dynamic table entries modification at work to handle the case the application evolves in an upper layer than the database does.

2. For the second question, why don't you just add an id column in your roles table ? A column for the id and a column for the name. Then all you have to do is to modify the name if it happens that it's really necessary. And when you have to check your role, you just query the id instead of the name, which allows name modification without introducing inconsistency.

My 0,002 cents :-)

Answer 3

Can't you have something like a trigger in your Role table DB that makes sure the necessary SysAdmin permissions are automatically added whenever any Create, Read, Update, Write entry gets added? i.e. Your Option 1 but with automation to ensure you do not have to manually remember to add the necessary permissions. Instead of a trigger you could also have a canned procedure that runs, say, every hour on the DB making sure that the SysAdmin user has all permissions?

Answer 4

What I typically do in your scenario (perhaps we'll call it option 3), is give the sysadmin role access to ONLY the parts of the system that are specific to that role. Don't check the sysadmin role anywhere else. Then, if you want any particular user to have access to the entire system, give that person all the roles necessary for complete access. The advantages of this are: there are no tedious updates to do every time you add a new feature, you don't have to check multiple roles in multiple places, and if you ever decide to give someone access to only the sysadmin portions without the rest of the site, you can.

For example, suppose you have 4 different sections of the site:

1. Accountant section - create a role called Accountant that can access this section.
2. Executive section - create a role called Executive that can access this section.
3. Employee section - create a role called Employee that can access this section.
4. System Administration section - create a role called SysAdmin that can access this section.

Now, each person is given 1-4 roles based on which portions of the site they are allowed to access. In your case the person who acts as the "System Administrator" would be given all 4 roles, so they can access everything on the site.

This method allows the most control over who can access which sections, and you don't have to change any existing code when you add new roles or sections to the site.