Building Blocks of Secure Applications

Most web sites and portals require the ability to identify users and protect the resources kept on the site. Even when allowing anonymous users to browse the information on your portal site, you still have to guard against intruders trying to take control of the internal resources of your site.

Building secure sites requires careful up-front planning and a clear understanding of the available options. The good news is that ASP.NET, in conjunction with Internet Information Server (IIS) and SQL Server, provides many out-of-the-box security features that require little or no coding and are easily configurable by administrators using wizards. The .NET Framework security model provides the ability to have low-level control on all security features without impeding the application's scalability or performance characteristics.

Four primary concepts underlie any security implementation:

• Authentication

• Authorization

• Impersonation

• Principals

Authentication

Authentication commonly refers to a process that verifies that the user is who the user claims to be. There are two sides to the process of authentication: gathering user credentials and validating these credentials against a chosen credentials authority. The types of credentials vary and may include a username and password collected using a login dialog box, a cookie saved on a user's computer, or credentials established by another credential authority ”for example, a Windows authentication mechanism.

The credentials authority could be represented by a custom validation process implemented by SQL Server, in the case of a massive online application, or by the Windows Kerberos or NTLM mechanisms, which authenticate users logging on to Windows NT, 2000, or later computers. When credentials are validated against some trusted authority, the user's identity is considered to be proven true.

Authorization

Authorization is another key security safeguard for building secure web applications. Authorization is the process of limiting access of authenticated users to only the resources these users are allowed to see. If your portal contains a document library, the process of authorization guarantees that each user will be able to access only the documents for which he or she has permissions. Almost all resources and objects in Windows are associated with access control lists (ACLs), which control who can access the resource and what that user can do with the resource (in other words, read, write, execute, delete). Each access control list consists of an ordered set of entries called access control entries (ACEs) that connect a security principal with a set of permissions (read, delete, and so on).

Impersonation

Impersonation enables the .NET code modules to change execution context based on the currently authenticated user. As a result, your application starts executing with privileges of the user account it impersonates. Impersonation is commonly used when an ASP.NET module receives the credentials of the authenticated user from IIS. Both IIS and ASP.NET perform an authentication and authorization process. By choosing to implement authentication at the IIS level and turn impersonation on in the ASP.NET application configuration file, you can avoid having to resolve authentication issues at the ASP.NET level. By default, impersonation is turned off.

Principals

A principal represents an authenticated user and carries the user's identity information. When dealing with security issues programmatically, .NET developers use principal objects. Principals are key elements in implementing .NET Framework role-based security.

There are three kinds of principals in .NET:

• Windows principals represent Windows users and groups. Windows principals can impersonate other Windows principals by assuming their identities.

• Generic principals represent users without connection with an existing Windows account.

• Custom principals are objects created by applications to implement specialized role-based security rules.