Tim Landgrave

Proper design of authorization mechanisms can make your systems easier to deploy and manage. By taking advantage of authorization based on enterprise authentication mechanisms such as Active Directory, your applications can integrate seamlessly with your company’s existing security policies. Authorization can be used in each tier for an n-tier application to create more flexible systems.

In the presentation tier, you can customize the user interface based on an authorized user’s role (e.g., displaying administrative menus for an administrative user but hiding them for a normal user). In the business tier, you can write code that verifies authorization in the body of the code, which minimizes a hacker’s, or other unauthorized user’s, ability to use a section of code without being properly authorized. In the data tier, requiring authorization before retrieving or inserting data can help insure that only the appropriate users make changes to the data.

Types of authorization
Authorization can take place at one or more of three different areas in a .NET system: Windows authorization, code access security (CAS) authorization, or application-specific authorization. Combining these authorization mechanisms allows you to create a very secure system. Let’s look at each of these in more detail.

Windows authorization
By setting permissions using Access Control Lists (ACLs), system administrators can control which users are allowed to have access to specific system resources. The administrators of the specific systems upon which the applications reside typically control these settings. Since the administrators in a production environment are typically different than those in a test or certification environment, it’s important that you document the specific authorization settings required for your application to operate. These settings may include:

  • Active directory permissions.
  • File permissions managed by NTFS.
  • Web Config settings, which limit access to specific URLs for ASP.NET-based applications.
  • Permissions specific to server products like Microsoft SQL Server (e.g., tables, views or stored procedures) or Microsoft Exchange (e.g., mailboxes, public folders, etc.).

CAS authorization
Windows authorization limits access to individual objects. CAS authorization, on the other hand, allows application code to execute based on a set of granted permissions (called a permission set). These permission sets are established based on evidence, including the code’s origin, its publisher, and its strong name. It’s important to understand that CAS authorization operates independently of any other authorization mechanism, allowing you to protect system resources regardless of the user’s authorization.

For example, if a permission set limits code coming from the Internet from deleting files on a user’s machine, that restriction is in place whether the user was authenticated as a system administrator or as a guest. You can configure CAS authorization using either the Caspol.exe command line utility or the Microsoft .NET Framework Configuration Console, which can be accessed from the control panel.

Application-specific authorization
Even if a user is authorized by Windows to perform an operation and the executing code has appropriate permissions, your application may determine whether the specific user is authorized to perform the operation. Creating an application-specific authorization framework allows your application to respond to different users based on their authenticated principal and gives you an additional level of control over what actions users can perform. The primary uses of application-specific authorization are to manage or limit access to specific application resources or to implement business rules that execute based on the authenticated principal.

I’ve used application-specific authorization extensively in both Web and Windows applications. In Web applications, I typically use it to dynamically generate menus so that users see only the particular menu choices that they’re authorized to use. For Windows applications, I embed authorization code into business logic to prevent users from executing code fragments that require higher levels of authentication. For authorization to be used and managed effectively, you need a common repository for permissions and a way to group users together so that you don’t have to configure individual users whenever permissions change.

The role of roles
The .NET Framework allows you to authorize a group of users with the same security privileges using roles. Managing roles rather than individual users means that your application doesn’t have to change when users move around. And it takes less time to administer your application when you can deal with five roles rather than 500 users. By using Active Directory as your authentication store, your .NET application can automatically use the built-in users and roles capability within Active Directory. Moreover, using integrated security with SQL Server extends these roles and associated permissions through to SQL Server objects, increasing the level of security without any additional coding.

Even if you choose not to use Active Directory, you can assign roles from external stores (e.g., SQL database tables, XML files, or even an external system using an interface like sockets) and verify role membership by coding directly against the IPrincipal object and the IsInRole method.

Authorization is a key design element of any .NET system. Once you understand the basics of the three major types of authorization, you can use one or more of them while designing your system.