Role-based security requires, at a minimum, two key elements: users and roles. Roles (such as Administrator, Clerk, and ViewOnlyUser) are defined by the application code and then assigned to users to restrict which functions of the application they may use. It's a pretty simple concept that involves all of two database tables, or one if the user names come from some external source like Active Directory.

In Adam's case, the Role-based security feature served as a coalmine canary in the application he was tasked with reviewing. Although it passed all of the test cases — employees could only do certain things, customers could do other things, etc. — there was one fundamental flaw with the system. See if you can spot it.

public bool IsInRole(string roleName)
{
   return UserName.StartsWith(roleName.Substring(0, 3));
}

The roleName parameter is a string ("Employee") that's is passed in from a method to check security, and UserName is just that: it's the user's name. So, users with a name that started with "Emp" would be granted access to Employee functions, while no one else would. And why "Emp"? As it turned out, the user names created for testing were "Employee1", "Employee2", "Employee3", and so on.

As for the rest of the system, it's development was similar: it passed the test cases and little more.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!