Role-Based Authorization in the Real World

Role-based authorization is a great method for programmatically controlling what actions a user is permitted to perform. You’ll encounter certain complexities beyond what is demonstrated in this chapter as you apply role-based authorization to your real-world scenarios. The most common issues you’ll deal with are how to best associate users with roles—either directly or by using groups—and what security approach to use for decentralized systems.

The examples presented in this chapter demonstrated a simple system in which roles are assigned directly to users. In larger real-world systems, you would probably bunch several users who share a common role together into a group. Figure 2-3 shows how this might work for Jane, who is both a data entry clerk and the person in charge of backups and is therefore a member of both the data entry personnel and backup administrators groups.

Figure 2-3: Jane’s permissions

Notice that both groups Jane belongs to have permission to log in to the system. The cumulative effect of Jane’s belonging to two groups is that she can log on to the system, add employees, and back up the database. Clearly Jane is on the way up in this organization. A benefit of role-based systems that apply to groups of users instead of individual users is that such a system provides greater flexibility and is easier to manage to support large and dynamic organizations.

For organizations that enjoy the benefits of a centralized Active Directory database for managing users and groups, the ActiveDirectory method is a good option. This option allows the application to be managed in one central location. It also means authentication can be done by Windows rather than inside your application. Authenticating within Windows is preferable because Windows already has security built in, which means it provides a rich set of tools and functions for implementing role-based security across your local network or intranet. Windows, for example, allows you to create network user accounts such as MYCOMPANY\UserName as part of a network domain in Active Directory—where MYCOMPANY represents the domain name. Once the user is authenticated within the domain, the user can access all resources such as network shares and intranet Web sites within the domain where the user (MYCOMPANY\UserName) has been authorized. If your application reuses the same authenticated username that was used to log on to the domain, it will be a convenience to the user, who won’t be hassled by another logon screen and forced to remember a separate username/password combination.

Organizations that do not use Active Directory to manage users and associated roles across the organization either rely on some other centralized management system such as LDAP, which stands for Lightweight Directory Application Protocol, or a database-based role management system as demonstrated by the first EMS exercise in this chapter. A database-based role management system is often used to authenticate Internet users connecting to a Web application such as an ASP.NET application. Online shopping applications, for example, commonly use a database to hold user information such as username and password—normally stored as a hash digest as presented in Chapter 1—in addition to shopping cart items; profile information such as address, telephone, credit card number; and preferences such as recently viewed items for that user.