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.

  • Have you think about option 2 with config file where you define admin user and password hash? Commented Jun 3, 2015 at 17:49

4 Answers 4


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.

  • 1
    The scalable option is to separate the security code from the rest
    – schroeder
    Commented Jun 3, 2015 at 23:22

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.

  1. 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 :-)

  • 1
    From looking at other software systems like Microsoft Dynamics, its pretty clear they use a full permissions system where the administrator gets all rights rather than hard-coding in a bypass. I just wasn't sure how manageable this option would be when features get removed or added or modified in some way by the application developers
    – volume one
    Commented Jun 3, 2015 at 22:13

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?

  • 1
    Yes I can. I could write a script that would do it. Its just I thought it may be hard to manage as the application grows bigger and some features change or get removed.
    – volume one
    Commented Jun 3, 2015 at 22:12
  • This also takes security semantics from the source code and into a script making maintenance more complex. Commented Jun 3, 2015 at 23:48

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.

  • Beside sysadmin there is need of appadmin role/user to manage application itself Commented Jun 3, 2015 at 18:53
  • @RomeoNinov. By "sysadmin" I meant "System Administrator" referred to by OP.
    – TTT
    Commented Jun 3, 2015 at 19:10
  • By sysadmin i mean person who will take care about accounts, roles, etc. By appadmin I mean person who will configure app, manage content and so on Commented Jun 3, 2015 at 19:15
  • So what you're saying is that Option 1 is the way to go in terms of making it a Role that has all permissions to the areas it needs. As apposed to hard-coding in a bypass into the application whenever it encounters a user with the status of System Administrator?
    – volume one
    Commented Jun 3, 2015 at 22:11
  • @volumeone. Not exactly. I updated my answer with an example to make it clearer. If designed this way, roles would never need to overlap. (No 2 roles would ever need to access the same section of the site.) In practice though, roles likely could overlap, since inevitably someone will want 1 role to be able to access a subset of an existing section, and it's easier to just give access to that part rather than split the section into multiple roles.
    – TTT
    Commented Jun 4, 2015 at 14:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .