One of the easiest ways to implement an authentication mechanism for a web service is to integrate it with the operating system. In this case, that would be Windows 2000. Windows allows for four different types of authentication:

Basic

As the name implies, this is the lowest level that security goes short of letting everyone in uncontested. The process involves transmitting both the user id and password that make up the credentials in cleartext to the web server. That's unencrypted, for the vernacular-challenged. This information is then validated against the security information maintainted by Windows.

The real beauty of using Basic authentication is how easy it is to set up. For IIS, you start by opening the Interset Services Manager and right click on the web site to view its properties. Under the Directory Security tab, click on the Edit button that is associated with Anonymous access and authentication control. Make sure that Anonymous Access is unchecked and Basic Authentication is checked, as well as Integrated Windows Authentication checked. This last field ensures that the user id and password that is provided must resolve to a valid user on this server.

Basic over SSL

This level of security follows the same steps as Basic authentication, with the exception that all of the transmissions are encrypted using the SSL protocol. The configuration steps are the same as with Basic, except that the web site is also configured to use SSL (the setup of which is beyond the scope of this article). Unfortunately, if every message is encrypted, there will be a performance impact. I have heard stories of a fifty-fold increase in response time, but studies that are much more rigorous in their methodology have indicated that you should expect a 60-80% increase.

Digest

The Digest authentication mechanism solves the performance issue by reducing some of the exchanges that SSL requires. The credentials are hashed on the client instead of going through the gyrations of requesting the necessary information from a certificate authority. The downside is that you will be limiting your list of valid browsers to Internet Explorer. This mechanism is not natively supported by the others.

Integrated

In this methodology, the user's credentials are transmitted to the web service using either NTLM or Kerberos. For the uninitiated, these are security mechanisms that are integrated into Windows 2000/XP. In other words, the service leaves it up to the operating system to determine who is valid and who isn't. While this is an efficient method, it again restricts your clients to using Internet Explorer. Not to mention that you must be using an intranet. Both NTLM and Kerberos are local authentication methods, so this option is not available if you want to expose your web service to the public at large.

Client Certificate

For really high end security, you could have your clients configure their browser to use certificates. The user would request and install a certificate from a trusted third party (i.e Verisign, Entrust, etc.). Then the web service could query their system to verify credentials as required. In order to function correctly in our web service context, the certificates must be linked on the server side to an existing user account.

While these are all valid choices and might very well be appropriate for your environment, there are drawbacks to utilizing any one of these options in our sample service. For example, since the Internet (and therefore web services) is stateless, the authentication information would need to be transmitted with every message. To me, this seems like a waste of both bandwidth and processing power. Perhaps the way to go would be to utilize a prepackaged solution from a third party.