Operating System Options
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.