Client Authentication

Server authentication is easy to understand ”its purpose is to verify the identity of the Web application owner. Client authentication, on the other hand, can be used for several purposes, including customizing content, charging for access, and sharing sensitive information. The following are some reasons to have client authentication:

• Customization based on client identity

• The ability to charge for access

• Protection of sensitive information

Some applications might customize their content depending on the user . Most of the search engine portal sites do this. If you log in to, say, Excite.com, it embeds your name , along with other options that you might have selected, in the main search page. Amazon.com also takes great advantage of customizing its pages when it knows who you are. For example, it looks at your history and sees what kinds of books you have been buying in the past, and displays books of similar type for a quick sale on its main page.

Other sites charge for access to their content. These sites must verify that the client has a current account and can access the requested content.

The third common need for client authentication is when there is sensitive information on the Web site. This can be financial information such as a stock portfolio, medical information such as a prescription plan, or employment information.

Each of these types of client authentication requires different levels of assurance, and they are implemented in several ways.

With IIS, it is possible to specify the level of client authentication to use for your Web application. If IIS performs client authentication, it requires more server involvement, which slows down the system. Therefore, IIS is defaulted not to perform client authentication. If client authentication is not selected, IIS treats every request as anonymous and a general account is used for credentials.

One of the most basic client authentications is when the client sends a password as clear text. Sending clear text makes sense only if the password is being encrypted. This type of authentication usually is used only in sites that use SSL. Although the password is encrypted, it is still available to scripts within the application through the AUTH_PASSWORD intrinsic variable. This might not be something you want for your applications. The integrated authentication tries to use native Windows authentications. The way native Windows authentication works is by negotiating Kerberos or NTLM with proprietary extensions to HTTP, and works only for clients running Internet Explorer that have a valid account on the server. This option is somewhat exclusive to local intranets and doesn't work well for Internet servers.

Digest authentication uses a challenge/response to verify a client password. For it to work, the password must be available on the server and must be a domain controller on the server network, which usually is not a good thing because someone could hack into your domain controller. And finally, in certificate authentication, the server requests a certificate of the client. To gain access, the client must have a valid certificate to present to the server.

SSL is not used in most Web applications because SSL puts added strain on the client, requiring clients to obtain a server account, a certificate, and so on. You probably will want your site to grant access to as many users as possible. What you should do is authenticate clients at the application level, and manage the details of keeping accounts and passwords within your site. This gives you much more control in designing your client authentication system and enables you to be more flexible as well.