ASP.NET Security

In "Get Ready for .NET," May 2002, InstantDoc ID 24479—the first article in my series about integrating IIS and ASP.NET—I introduced you to the Microsoft .NET Framework and showed you how to get your hands on it. I also explained the .NET Framework's two major components: the Common Language Runtime (CLR) and the .NET Framework class library. You must have a good understanding of the .NET Framework before you even consider installing it in your production environment. This month, I dig a little deeper into the inner workings of ASP.NET in relation to designing, configuring, and implementing ASP.NET's security architecture.

ASP.NET's Security Architecture
Browser-based clients communicate with ASP.NET through IIS, which translates and optionally authenticates the request. (I say "optionally" because no authentication occurs if you enable Anonymous access.) In addition, IIS finds the requested resource (i.e., the ASP.NET application's home page, default.aspx) and, if the client is authenticated and authorized, returns the resource to the client's browser. Figure 1, page 2, shows this communications process.

In addition to using built-in ASP.NET security features such as role-based security, an ASP.NET application can use low-level security features (e.g., code-access security) of the .NET Framework. Role-based security and code-access security can help software developers and IIS administrators design and deploy applications with robust security features such as principals, authentication, authorization, permissions, type safety and security, and security policies.

Principals. A principal characterizes the identity and role of a user. The principal acts by proxy on an authenticated user's behalf. Role-based security in the .NET Framework supports three kinds of principals:

• Generic principals represent users and roles that exist independent of Windows .NET Server (Win.NET Server), Windows 2000, or Windows NT server users and roles.
• Windows principals represent Windows users and their roles. Windows principals also represent Win.NET Server, Win2K, and NT server groups. A Windows principal can impersonate another user, which means that the principal can access a resource by proxy on a user's behalf.
• Custom principals are defined by software architects to meet the unique needs that applications with role-based security have beyond what the .NET Framework provides.

Authentication. Authentication is the process of discovering and verifying a principal's identity by examining the user's credentials and validating those credentials against an authority. An authority can be one of several authentication mechanisms, including Basic authentication, Digest authentication, OS schemes (e.g., Kerberos, NT LAN Manager—NTLM), or application-defined mechanisms. Most of these authentication mechanisms work seamlessly with .NET Framework's role-based security.

Authorization. Authorization is the process of determining whether a principal can perform a requested action. Authorization occurs after authentication and uses information about the principal's identity and roles to determine what resources the principal can access. Authorization is implemented in the .NET Framework by a robust role-based security system.

Permissions. The .NET Framework offers three kinds of permissions, each with a specific purpose:

• Code-access permissions provide access to a protected resource or provide the ability to perform a protected operation.
• Identity permissions provide code with credentials that support a particular kind of identity (e.g., PublisherIdentityPermission, which is a software publisher's digital signature).
• Role-based security permissions provide a mechanism for discovering whether a user (or the agent or piece of code acting on the user's behalf) has a particular identity or is a member of a specified role.

Type safety and security. Type-safe ASP.NET code accesses only the memory locations it's authorized to access. When ASP.NET code is type safe, the CLR can completely isolate assemblies (i.e., groups of programming constructs contained in files that are built, versioned, and deployed as one implementation unit) from one another. Type-safe components can execute safely in the same process. When code isn't type safe, you have large security risks such as those you see exploited by today's viruses. For example, the CLR can't prevent code that isn't type safe from calling native (i.e., unmanaged) code and performing malicious operations. When code is type safe, the CLR's security mechanisms ensure that the code doesn't access native code unless the software developer has specifically given it permission to do so.

Security policies. A security policy is a configurable set of rules by which the CLR abides when the code has calculated the roles to determine the security policy. You set the security policy in the Microsoft Management Console (MMC) Code Access Security Policy snap-in, and the CLR enforces the policy.

Authentication: The Connection Between ASP.NET and IIS
The relationship between ASP.NET authentication and the IIS authentication services is important. IIS always assumes that a set of credentials will map to a Windows account, and IIS uses those credentials to authenticate a user. You configure the type of authentication mechanism in the MMC Internet Information Services snap-in by right-clicking the Web server or virtual directory, then selecting Properties. Click the Directory Security tab, then click Edit in the Anonymous access and authentication section to access the Authentication Methods dialog box, which Figure 2 shows.

IIS 5.0 offers three authentication schemes: Basic, Digest, and Integrated Windows authentication with either NTLM or Kerberos. (For an explanation of how Integrated Windows authentication works with NTLM and Kerberos, see Leon Braginski, "Kerberos vs. NTLM," May 2002, InstantDoc ID 24473.) In addition to these three methods, IIS 6.0 offers Passport authentication. However, because the Win.NET Server family of servers (of which IIS 6.0 is a part) hasn't shipped yet, Passport authentication services are available only as a centralized authentication service that Microsoft provides. ASP.NET offers this modified form of Passport authentication. (Licensing costs are involved in using Passport as an authentication mechanism, so consult the .NET Passport Web site at http://www.microsoft.com/passport for details.)