Role-Based Access with Authorization Manager

In the broad spectrum of security, authentication and authorization are often grouped together, but they differ greatly. Authentication answers the question "Who is this user?" Authorization answers the question "What can this user do?"

Because authentication and authorization differ, you achieve them in different ways. Achieving authentication is easy if you follow a few best practices. One of those best practices is to use the Windows Server OS for authentication when possible. The OS takes care of many authentication details, and the platform stores the users' credentials. For example, you can use Windows Server 2003's Active Directory (AD) to authenticate Microsoft IIS users.

In contrast, authorization was historically tough to achieve because you had to use custom-built applications. However, Windows 2003 has changed that situation by providing a feature called Authorization Manager. Combined with Windows .NET Framework's role-based security, Authorization Manager is a powerful tool.

Since Windows NT 4.0, administrators were able to secure OS resources (e.g., file-system objects) with ACLs. In the ACL approach, you can attach discretionary ACLs (DACLs) to a persistent object and call the AccessCheck API to make access decisions. The API looks at a user's group memberships and compares them against the ACL's contents to determine whether the user has the necessary access rights.

Applications that don't have well-defined persistent objects have no place to put an ACL, so the ACL approach can be difficult, if not impossible, to apply in these applications. Line of business (LOB) applications often fall into this category. Fortunately, Authorization Manager provides an authorization framework that you can use when you need to give users access to an LOB application. Instead of determining whether to grant access based on ACLs, Authorization Manager determines whether to grant access based on "roles" that you assign. A role is an object to which you assign access permissions to certain resources. You can think of a role as a job position; you assign a position the rights to access any resource it needs. You then assign users to appropriate roles.

Authorization Manager consists of a set of COM-based runtime interfaces and the Microsoft Management Console (MMC) Authorization Manager snap-in. Applications written in ASP.NET use the Authorization Manager API through the interop assembly that ships in the \AuthMan directory in the Framework.

You can integrate Authorization Manager with Internet Information Services (IIS) 6.0 to implement IIS 6.0 URL authorization, which lets you authorize users' access to URLs in a Web application. When a client requests a URL, IIS 6.0 URL authorization validates a user's access based on that user's specified role. You control access to URLs by using custom roles, Lightweight Directory Access Protocol (LDAP) queries, and dynamic business rules (BizRules). BizRules let you take runtime data into account.

Although Authorization Manager was a barely known feature at first, it's starting to gain popularity as people discover its power. According to Microsoft, Authorization Manager's goals are to simplify application access-control administration, provide a simplified and natural application-development model, and enable flexible and dynamic authorization decisions. Authorization Manager meets those goals. The bottom line is that Authorization Manager provides role-based authorization security that's not only part of the platform but also easy to use. You can find more information about Authorization Manager at the following four sites: