Web services are a fantastic tool for building distributed applications, and the fact that they are composed of XML and SOAP make them cross-platform by nature. However, one of the problems with Web services is that they are typically open to anyone who calls them. So developers must find a way to expose the service, while still being able to control who has access to it.

Although there are standards in the works for Web service user authentication and security, to date, they are still proposals and not much help to those of us already building Web services. In the absence of any standards, a couple of approaches have come up for controlling access: The first is to validate the user programmatically in the service itself; the other approach relies on the Web server (usually IIS) to validate the user for you.

Programmatic validation: Simple, but easily defeated
The way most people control access to Web services is to require some kind of key be passed with each method call. The beauty of this approach lies in its simplicity: If someone fails to pass you an appropriate value, the call fails, and the person is denied access to the service. Listing A presents the canonical currency conversion Web service that uses key-driven programmatic validation to control access.

The PoundsToDollars function accepts a string key value as its second argument, and passes this key value to the private ValidateUser function where the key is validated. At its simplest, the ValidateUser function could simply compare the key with a hardcoded value and return a value of True if they match. More likely, each new customer will be assigned a key value, and you will look these keys up in a database.

The risk with this approach is that nothing prevents users from sharing their keys with others, which would allow unauthorized users access to the Web service. To get around this potential pitfall, you could capture the incoming IP address and mix your key validation against the IP address, but doing so would remove the users’ ability to use the service from different locations. For example, if a hypothetical component were to be used by a mobile sales force, they might be dialing in from the road with a new IP address each time. Looking for specific IP addresses as part of your validation scheme wouldn’t work in this case.

Using programmatic validation has a number of other advantages and disadvantages, including the ones listed below.

Programmatic validation pros

  • ·        Simple to implement—Using programmatic validation is simple. You accept a key and then create a validation routine that is as simple or complex as you desire.
  • ·        No server administration required—When you use programmatic validation, you’re typically not dependent on a server administrator to create accounts for you whenever you add a new customer.

Programmatic validation cons

  • ·        Easy to lose control—As soon as someone shares his or her key, your service is open to that other person. Depending on how you are validating the users, you might have to modify a database table or actually modify and recompile your Web service.
  • ·        Have to pass extra data—Each Web method will have to accept this key value. That will require extra effort on the part of the developer consuming your service and extra data being passed with the call.

Operating system validation: The client’s responsibility
You can also have the operating system perform user authentication through IIS. In this way, IIS’s basic authentication features protect access to the virtual directory containing the Web service and require a user ID and password to access the directory. Your user’s client will need a user ID and password to use the service, which may be inconvenient for the developers consuming the service. However, this method prevents the Web service developer from having to build a validation routine and maintain a list of valid keys.

One advantage of using operating system authentication in IIS is that your Web service can be coded without regard to user validation and tested without requiring any validation. You can then turn on basic authentication for its virtual directory when the service is ready to be deployed. From that point on, IIS handles all authentication issues before the Web service is even reached.

While programmatic validation requires both the client and Web service to provide parts of the validation logic, using operating system authentication means that only the client has any authentication logic. The client application must create a System.Net.NetworkCredential object to encapsulate the user ID and password. After the client app sets the Credentials property of the Web service to the NetworkCredential object that it created, it can call the Web service method normally. It’s also possible to set the Credentials property at an application level so that the data need only be passed once during the lifetime of the application.

The author of the client application who is presented with responsibility for creating the credentials required to use the service has several options: Hard-code the user ID and password in the application, require the user to enter a user ID and password, or grab the user ID and password from a database. The first of these options is demonstrated in Listing B. Note that there’s no need to pass any form of key to the Web service method when it’s invoked.

While using operating system authentication has some advantages, it isn’t perfect. Some of the pros and cons of using basic authentication include:

Operating system validation pros

  • ·        No coding required in the Web service—You can implement operating system authentication on any existing Web service without writing any extra code, because validation is handled by the operating system before the Web service is reached.
  • ·        Simplified functions—Each function requires only the data on which it operates. There’s no need for a separate key parameter or a validation function. The client application doesn’t have to pass a key with each call to the Web service.

Operating system validation cons

  • ·        Administrator required—You’ll need to have a capable administrator to turn on basic authentication and keep the service’s user and password lists up to date.
  • ·        More complicated for the client developer—The client application needs to store and retrieve the username and password in some way. Whether this is hard-coded into the application, read at runtime, or entered by the user, it is important to make sure this information is passed.

No perfect answer
Unfortunately, there is, as of now, no perfect answer to the problem of securing access to Web services, but the general idea is to make the client pass some sort of validation information to the service. How that task is accomplished is the critical decision to make. One of the two approaches explained here may be a good choice for your particular situation.