Chapter 2: Role-Based Authorization

Overview

Key concepts in this chapter are:

• Applying role-based security techniques to your applications

• Using Microsoft Windows role-based security

• Enabling or disabling application options depending on the user’s role

• Using role-based authorization in ASP.NET applications

Role-based security allows you to programmatically control what actions users are permitted to perform. This security strategy has its basis in roles that we as employees, managers, customers, and vendors play in life.

Each role encompasses its own set of rights or permissions. For example, part of a manager’s role is to review the compensation for each of her employees. The manager’s role grants the manager permission to access the salary information for an employee. The employee’s role grants the employee the right to view his own compensation, but no one else’s.

As employees, people play different roles in the execution of a shared goal or task. For example, suppose your company’s goal is to sell miniature plastic dinosaurs online. Your customers, suppliers, accountants, lawyers, and product-support personnel all play different roles in not only the sale of plastic dinosaurs, but also in handling the aftermath of the sale. You need people in various roles to manage the resulting revenue, inventory levels, and customer complaints.

In some cases, your employees might fulfill more than one role. For example, an employee might handle incoming shipments and also have access to a supplier’s invoice system. If the employee is honest, you have nothing to worry about; if he is not honest, the employee could, for example, take a shipment and erase any record of it from the supplier’s invoice system, leaving you a truckload short of plastic dinosaurs. Such a system could also lend itself to honest mistakes. For example, suppose an employee is expected to manually handle both parts of a transaction—such as separately updating the incoming shipment’s registry and the supplier’s database. The employee might update the shipment registry but then get interrupted and forget to request the shipment. When you design your online system, you should strive to accomplish the following goals:

• Allow each person to accomplish her assigned task and no more. This is known as the principle of least privilege.

• Divide areas of responsibility so that no single person can intentionally or unintentionally compromise or deliberately cheat the system.

• Allow the system to be audited by those not involved in the transactions; and prevent those involved in the transactions from being able to view the audit logs.

You can accomplish these goals by incorporating role-based security in your application. Microsoft Visual Basic .NET provides the building blocks necessary to implement role-based security: objects based on the concept of Identity and Principal. You can use Identity and Principal to limit what the user can do within your application. This satisfies the first goal of letting a person do what she needs to do but no more—the principle of least privilege. Identity identifies the user by username and Principal combines Identity with a list of roles that the user plays. Identity and Principal enable you to divide areas of responsibility by assigning different users to different roles, and they allow users to share areas of responsibility where needed by assigning more than one user to the same role. As an example, the employee management system (EMS) for our fictional company uses objects based on Identity and Principal, as demonstrated later in this chapter, to enforce roles such as the following:

• Employee—To allow all employees of the organization to view their own personnel information.

• Manager—To allow a manager to view personnel information for all of her direct reports.

• Human Resource Officer—To permit adding employees to and removing employees from the employee management system.

• Human Resource Administrator—To add or remove roles that other employees perform, such as adding the manager’s role to an employee who has been promoted to manager.

• Auditor—To allow one or more users not involved in the transactions to verify the integrity of the system. The Auditor can view all actions taken by the other roles, but cannot change any of the information.

When you give people access to applications, you are assigning two privileges: who can use the application, and who can do what in the application. In security terms, these privileges are enforced using two mechanisms referred to as authentication and authorization. Authentication verifies you are who you say you are, and authorization verifies you are permitted to perform a specific activity. If you provide a login dialog box—as shown in Chapter 1—you are providing a means of authentication. The user must be authenticated before being allowed to use your application. Once authenticated, the user is given authorization to perform only those tasks that your application allows him to perform. This chapter covers how you can use role-based security techniques to control what users can do—or what authorization they have—after they have successfully logged on.

The Identity and Principal Objects

An Identity is an object that contains a user name such as ERobinson or MBond. The Identity object typically represents the logged-on user, but it can represent any user whose rights are used to determine what tasks are allowed to be performed. Microsoft Visual Basic .NET provides a set of standard Identity objects representing users logged on to the system from different logon services:

• WindowsIdentity

• FormsIdentity

• PassportIdentity

• GenericIdentity

  All Identity objects have in common a useful property called Name, which returns the name of the currently logged-on user. For example, to return the name of the current Windows user in the form of Domain name\username, use the following code:

Dim strUsername As String
'Imports System.Security.Principal.is required
strUsername = WindowsIdentity.GetCurrent.Name

The Principal object combines two important pieces of information needed to implement role-based security:

• The user name or identity, as we just discussed

• The roles that the user belongs to

Visual Basic .NET provides the following Principal objects, which work with the Identity objects listed previously:

• WindowsPrincipal

• GenericPrincipal

Note

The GenericIdentity and GenericPrincipal objects are used to implement a custom role-based security model within your application as shown in the next exercise. The other Identity objects—WindowsIdentity, FormsIdentity, and PassportIdentity—are useful for integrating existing authentication models in your application. Of these objects, only WindowsIdentity has an associated Principal object—the WindowsPrincipal. The reason for this is that Windows has a built-in authorization model providing groups as a way of associating roles with users. The WindowsPrincipal contains the group names—such as administrators, power users, and users—as the list of roles for which the user is a member. The Forms and Passport authentication models do not provide associated authorization models and do not provide a built-in set of roles; therefore, Principal objects having names such as FormsPrincipal or PassportPrincipal do not exist.