Archive

Archive for the ‘Programming’ 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.

Careful with That Axe, Eugene – Using ToString() with a .Net Decimal Type

September 11, 2009 Leave a comment

A Problem With Decimals

Yesterday I ran into a problem with the ToString() function on a .Net Decimal type.

Actually the problem was mine but it revealed something I didn’t know about Decimal types that actually IS in the documentation but no one really reads the documentation, do they? Well they do when they run into problems.

Try the following in a .Net console application (C# or VB.Net or whatever you prefer):

    decimal dec1 = 10.0M;
    decimal dec2 = Decimal.Parse("10.00");
    Console.Write("dec1 == dec2 : ");
    Console.WriteLine(dec1 == dec2);
    Console.Write("dec1.ToString() == dec2.ToString() : ");
    Console.WriteLine(dec1.ToString() == dec2.ToString());

The output is the following:

dec1 == dec2 : True

dec1.ToString() == dec2.ToString() : False

Now, both dec1 and dec2 contain a decimal 10 value so mathematically they are equal, but the output of ToString() for each of them is:

dec1.ToString() : 10.0

dec2.ToString() : 10.00

So you see the strings are not identical.

The Reason Behind It

The reason that the two ToString() calls are not equal is because Decimal preserves the position of the decimal point so when we parse the string “10.00” both zeros to the right of the decimal point are kept.

This is all detailed in the MSDN documentation on the Decimal structure :

The scaling factor also preserves any trailing zeroes in a Decimal number. Trailing zeroes do not affect the value of a Decimal number in arithmetic or comparison operations. However, trailing zeroes can be revealed by the ToString method if an appropriate format string is applied.

I stumbled upon this while working on the Serialize/De-serialize functions of PropertyTree a data structure that I will post about soon (really).

Technorati Tags: ,
Categories: .Net, Programming Tags: