HTTP Security

In .NET, network application communication happens not only with sockets over TCP and UDP, but also when communicating with HTTP. Chapter 10 showed that Web classes can be built around communicating over HTTP without worrying about the underlying network socket communication. And Chapter 11 demonstrated that Web services use HTTP to communicate with ASP.NET on a Web server. HTTP is a simple protocol that is request-response oriented. The client makes a request to the server to perform some action. The server receives the request and generates a response that is returned to the client. Following the response, the entity or content being requested is transmitted.

When clients attempt to request resources on an HTTP server, the server can optionally require a client to identify itself by using authentication mechanisms. The HTTP 1.1 specification defines optional challenge-response authentication mechanisms named Basic and Digest by which means a server can challenge a client request to provide authentication information when accessing resources. An HTTP server that supports the HTTP 1.1 specification must at least provide Basic and Digest authentication support. However, the server is free to implement additional authentication mechanisms such as Forms-based authentication. Microsoft Internet Information Server (IIS) is a Web server that offers secure communication through HTTP by providing authentication and authorization to Web resources.

Authentication Schemes in IIS

IIS version 6 features several forms of authentication to secure Web resources ” Anonymous, Basic, Digest, Integrated, and Certificate. Working in conjunction with ASP.NET, IIS also provides Forms- and Passport-based authentication.

Anonymous

Anonymous authentication is not very secure because the client that is accessing a resource is not positively identified. Although Anonymous is not secure, it is needed for Web resources that are meant to be freely shared with clients, such as the launch page of a retail catalog Web site.

Basic

Basic authentication is a simple password-based authentication scheme supported by most Web browsers. When a Web resource is protected using basic authentication, IIS prompts users for a valid user account and password. The password information travels unencrypted over a network, however, which means that Basic authentication is not very secure even though it can identify a user. One way to make Basic more secure is to only use it over a Secure Sockets Layer (SSL) connection, which will be described later in this chapter.

Digest

Digest is another password-based authentication scheme similar to Basic authentication. User credentials are hashed and encrypted, however, typically using the MD5 message digest algorithm (see RFC 1321), when they are passed over the network during authentication, which makes the scheme more secure. The big advantage of Digest is that it can be easily deployed over the Internet to protect resources.

Integrated

Integrated authentication, also known as Windows authentication, is an authentication scheme that uses NTLM or Kerberos to authenticate users that are a part of a Windows domain. The nice thing about Integrated Windows authentication is that the authentication step is transparent to a client, such as a Web browser, because the user s domain logon credentials are used to perform authentication. Windows authentication operates well in an intranet scenario. It does not work well on the Internet, however, because Windows domains are normally managed at the business organizational level rather than across the Internet.

Certificates

Certificate authentication uses public and private key security technologies to identify clients. The .NET Framework supports the use of X.509 version 3 certificates, which are a mechanism for validating that the private and public keys used to access a resource are correct. Chapter 10 described certificates used with the HttpWebRequest class.

Forms

Forms authentication is a mechanism that causes a user logging on to a secure Web site to receive an encrypted cookie that is used to access secure resources at the Web site. When the user first attempts to access a secured resource, HTTP client-side redirection sends the user to a form for providing authentication credentials. If the credentials satisfy the secure Web site, the client receives a cookie that contains an authentication ticket. Typically, the redirected connection to the form runs over SSL to handle the authentication step. Once authenticated, the cookie is used to identify the client everytime a request is made to a secure resource. Forms-based authentication is only available in IIS from ASP.NET. Forms authentication allows you to develop a custom data store to manage credentials and authentication, which is usually handled by a Microsoft SQL Server database.

Passport

Passport authentication is similar to forms-based authentication where a client is redirected to an authentication server to receive a cookie containing an authentication ticket. The main difference is that the passport authentication service is centrally managed by Microsoft to authenticate HTTP clients. Passport is designed to standardize the authentication step by using one user account and password for all Web sites that support Passport authentication. The idea is to reduce a customer need to access Web sites with different logon credentials.

The .NET Framework Web class HttpWebRequest does not support forms- based authentication or Passport authentication, because the class does not handle the client-side redirection step needed to authenticate a client. For example, a request to a resource that is protected by forms-based authentication would be challenged by the server sending a redirect to a login page. This model works well for graphical clients such as a browser, but does not work well for clients that run as a service or contain no user interface. HttpWebRequest supports password-based authentication schemes, which are Basic, Digest, Integrated, and custom.

Choosing an Authentication Scheme

With so many authentication schemes available in IIS for HTTP communication, how do you decide which one to choose when designing an application? There are several factors to consider, such as browser type and accessibility of the authentication scheme. Table 13-3 provides a comparison overview for each scheme.

Table 13-3: Comparison of Authentication Schemes

Authentication Scheme	Advantages	Disadvantages
Basic	Used by most Web browsers. Far reach over the Internet.	Not a secure authentication scheme because passwords travel over a connection without encryption. Must use SSL to make authentication secure. Must maintain a user account database.
Digest	Used by Web browsers supporting HTTP 1.1. Passwords are encrypted over the wire. Far reach over the Internet.	Must maintain a user account database.
Integrated	User account management is handled by a Windows Domain.	Does not have far reach over the Internet and is useful only in intranet scenarios.
Certificate	Far reach over the Internet. Works with all Web browsers.	Clients must have X.509 certificates.
Forms	Far reach over the Internet. Works with all Web browsers. Easy to develop using ASP.NET.	Does not work with HTTP Web classes because it requires interaction with the user. Must use SSL to make authentication method secure. Must maintain a user account database.
Passport	Far reach over the Internet. Centralized single-user account to access Web sites supporting Passport. Works with all Web browsers.	Does not work with HTTP Web classes because Passport requires user interaction.

Choosing the correct authentication scheme really depends on the deployment scenario of your .NET application. For example, do you expect all your clients to use the same Web browser? Do you plan on deploying your application only in an intranet scenario where all your clients have a Windows account? Does you application work over the Internet? Knowing the answers to these questions will help you decide what authentication scheme is appropriate.

Preauthentication

Preauthentication is a method that allows an HTTP client to supply user credentials via an Authorization header so a Web server will not have to perform an authentication challenge using a WWW-authenticate header when a client application accesses a secure Web resource. The reason for it is to reduce the communications needed to set up and authenticate a client. Preauthentication is only supported by Basic and Digest authentication schemes. The HttpWebRequest class supports preauthentication by allowing a client application to supply authentication credentials.

Web Services

The ASP.NET Web service uses HTTP and HTTPS to communicate over a network. Once a client has been authenticated by IIS or by ASP.NET, the authenticated identity of the client is used by ASP.NET to authorize access to specific Web resources.

Authorization

In ASP.NET, authorization determines whether an authenticated client has been granted access to a given resource. ASP.NET handles authorization in two ways, which are URL authorization and File authorization.

URL Authorization

URL authorization determines which users have access to specific URL resources by defining access in the Web.config control file for ASP.NET. In the Web.config XML file, the <authorization> section allows you to allow or deny specific users or groups to a specific URL.

File Authorization

File authorization requires the use of Windows authentication to apply an access control list (ACL) on Web resources. ACLs on Web resources are supported only if the file system is formatted using NTFS. ASP.NET applications can use impersonation to control the security of Web file resources. In an ASP.NET application, the application can execute using client-authentication identification. For example, you can lock specific file resources for specific users or groups that have been authenticated by Windows authentication.

Web services offer good security control of Web resources using IIS when communicating over HTTP. .NET remoting also benefits from the authentication and authorization security mechanisms of IIS.

.NET Remoting

.NET remoting allows you to build highly distributed applications that can communicate securely over a network by using HTTP and IIS to host remoting. Using IIS to host remoting allows you to authenticate the user attempting to access a remoted class. It also allows you to securely transmit data over HTTPS (SSL). The HTTP channel offers most of the authentication schemes in IIS except for Forms or Passport authentication. The TCP channel for remoting currently does not offer the security mechanisms available in the HTTP channel. See Chapter 12 for more information on .NET remoting.

Secure Sockets Layer

SSL is a protocol that allows Web servers and Web clients to communicate securely by using data encryption for the HTTP communication. One of the great advantages of using SSL in the .NET Framework Web classes is that SSL support is nearly transparent. The only difference between a normal request and an SSL-encrypted request is that the URI scheme is HTTPS instead of HTTP . The SSL negotiation that occurs to establish the underlying connection, send the request, and retrieve the response is transparent and requires no intervention by the application.