Archive for the ‘Security’ Category

Us and Them – Privilege Based versus Role Based Security

October 3, 2009 Leave a comment

I’d like to talk about Privilege-based security because I haven’t found anything on the Web about it and I really think you should consider it if you haven’t already done so.

A bit of history

A while back when programmers added security to their applications they would assign rights to access functions of a program directly to individual users defined in some Users table. They would then use code like the following to perform authorization to a given right:

if (user.CanCreateDocument == true) { 
        // Allow some document creation

Of course this meant that every right had to be assigned or denied individually to each user, this made for an administration nightmare.

With the introduction of Role based security a level of indirection was introduced that simplified administration. Rights to functions were granted to Roles and roles were assigned to Users, usually with entries in a security database.

Now when you performed authorization you used code like the following:

if (user.BelongsToRole("Administrators")) { 
        // Allow some code

This simplified administration because now you only needed to assign (or remove) a right to a role in the security database and all members of that role would acquire the right.

The problem I have with Role based security

Of course you probably know all this and have used it so you’re asking "What’s the problem?", well recently while working on the security system of a framework on my day job I came across the following problem: users can change their personal passwords on our system and also users who belong to the Administrators role can also change the password of any user. You can see this in this code example:

if (user == userToUpdate || user.BelongsToRole("Administrators")) { 
        // Change the password

Again you’re asking "So what’s the problem?", well the customer later required that a Supervisor be able to change a users password but that supervisor could not be member of the application Administrators role because that would grant Supervisors too many rights. "No problem, just create another role, right?" well you can but this is my problem, the authorization code would have to change like so:

if (user == userToUpdate || user.BelongsToRole("Administrators") 
    || user.BelongsToRole("Supervisors"))
        // Change the password

In fact any time you need to add a new role for an existing right you have to edit the code to test for the new role and recompile. Now maybe this doesn’t happen too often but if the code is already in the field you just traded an administration nightmare for a deployment one.

Why use Privilege based security

With Privilege based security you create a privilege for every function in code that needs authorization and you test for this:

if (user == userToUpdate || user.HasPrivilege("ChangeUserPassword")
        // Change the password

You then assign privileges to roles and when you need to, you can create new roles and assign existing privileges without needing to recompile.

In fact, you could assign (or deny) certain users privileges beyond those found in the roles that they belong to.

In the Real world

When applying this model in our framework, we did find that the more granular the security requirements of an application the more privileges where needed. This added more administrative work if the privileges were assigned individually to roles.

Our solution to this problem was to organize privileges hierarchically and permit the assignment or denial of privileges to be inherited to all sub-privileges of a privilege. For example we created the following privilege tree:

+ Security

+—+ User

      +–+ Create User

           + Delete User

           + View User Profile

           + Change User Password

If we assign the User privilege to a Role then that role is allowed all privileges underneath (i.e. Create User, Delete User, View User Profile and Change User Password). This is similar to how security works in the NTFS File system.

In conclusion

Privilege based security adds a level of flexibility to the already proven Role based security model by creating a single privilege in code for each function in a program that needs to be secured and then assigning that privilege to any roles that require it in a security database. Administrators can then customize and adapt security to real world requirements in the field without recompiling existing code.