In this chapter, we jumped right into encryption and created a library of functions for creating hash digests as well as for encryption and decryption using private and public keys, all with a single line of Visual Basic code. In addition, we started securing the employee management system with minimal impact on usability and programming time. This illustrates an important point: if security is complicated to implement or use, people won’t implement or use it. The purpose of this and future chapters is to show you techniques that are simple to bolt onto your existing applications and that have minimal impact on usability.
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
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
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
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
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
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
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 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
An Identity is an object that contains a user
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:
objects are used to implement a custom role-based security model within your application as shown in the