Secure Web services

This is the second installment of a three-part article examining techniques used to architect secure Web services. Part one introduced a fictional company, The Internet Dictionary Company (TIDC) and its customer, RegalResearch.com. Regal Research uses a Web service to integrate the TIDC functionality into its own site. The first installment also illustrated the first technique for securing the TIDC Web service, IP blocking. In this installment, we will discuss two additional techniques: user authentication and digital certificates.
User authentication
User authentication is a common technique found in many types of software ranging from databases to operating systems (see Figure A). The concept is simple: Each user for the system is assigned a unique username. Access to resources or functionality associated with that username is protected by knowledge of a specific password. The ubiquity of user authentication systems is beneficial for Web services because most users are already comfortable with this security technique. Whether your Web service is being consumed by other Web developers or by the general public, this security mechanism is easily understood.

Figure A

User authentication allows individualized use of Web methods.

Applying user authentication security to Web services is simple enough: Each Web method call requires two additional parameters, username and password. Each time a Web method is called, the first action taken will be to check that the username exists in the database. The second step is to ensure that the password provided matches the password for the specified username. If both of these checks pass, then operation of the Web method continues normally. If either of these checks fails, the Web method needs to provide some sort of error message to the calling function.
A common variation to this technique is to require just a user identification code, typically a Globally Unique IDentifier (GUID). In this case, the Web method call accepts one parameter, UserID, in addition to its standard parameters. This approach is usually just as effective as using a username/password combination because GUIDs are very hard to duplicate. In most cases, it is much more difficult to randomly determine a user's GUID than their string-based password. This is also a popular technique because many databases will automatically generate a GUID. The main detriment to this technique is that a GUID is more difficult for a user or developer to remember and is easy to mistype.
Benefits
An important benefit of user authentication is the option of creating more complex authorization schemes. Remember that authentication is the process of proving the user's identity and authorization is the process of identifying resources accessible by that user. Since each Web method has to authenticate the specific user making the request, it is possible to create a complex authorization scheme where users are authorized to use only a portion of the available Web methods. In this case, after authenticating the user, each Web method would make one additional check to determine if the authenticated user should be allowed to access the given Web method. If no authorization exists, then a third type of error message would be presented to the user.
The downside
There is, of course, a downside to using user authentication to secure your Web services. The most obvious problem with this scheme is that the user has to include one or two additional parameters in every single method call. When a server-side Web application (such as ASP or JSP) is doing this work, this typically is not a problem. However, when humans are making direct calls to the Web method through a WSDL page or similar front-end, this effort quickly becomes tedious.
Another major concern when using user authentication is the requirement to store username/password combinations on the Web server. These are typically stored in a database requiring additional database storage space and requests, which can impact Web service performance. Storing this data also potentially exposes sensitive customer information to employees and hackers. With Web services that use a database for their basic functionality, this concern can be mitigated by good architecture and development. For Web services that do not require a database, the price of creating and maintaining one just for user authentication is often too steep.
Digital certificates
Another option for securing Web services is digital certificates. Digital certificates are small pieces of software installed on client machines that verify the client's identity (see Figure B). This verification is done through a third-party such as Verisign that creates a unique certificate for every client machine using industry standard encryption. The certificate is then passed along when the client requests a Web service. The Web service checks for the presence of the digital certificate and reacts accordingly.

Figure B

Digital certificates identify a user securely.

Digital certificates are typically used in a fashion similar to IP blocking, in an "all or nothing" prospect for the whole site. Each Web service usually calls a single function, which verifies that a certificate was passed along with the request. If the function indicates that no certificate was passed, the Web service fails and returns an appropriate error message. If the certificate is present, then functionality is executed normally. In this scenario, digital certificates work similarly to IP blocking in that server-side configuration and maintenance is easy, at the cost of flexibility.
Benefits
Digital certificates have a significant benefit over IP blocking. Like user authentication, the security check for digital certificates doesn't occur until a Web method call is actually made. Thus, visitors can still view the WSDL pages for Web services or associated Web pages. This benefit comes at the cost of having to include code in each and every method that requires it. If you forget to include the code in one Web method, that method will be freely available to anyone who wants to use it.
Since you have to include authentication code in every Web method anyway, many developers take the opportunity to expand on the simple usage of digital certificates described above. Digital certificates can hold personal information about the user (presumably) sitting at the client machine, so this code can resemble the code needed for user authentication. A common piece of information contained in a digital certificate is the user's e-mail address. This can easily be used as the identifying key in the database since it is always unique. Furthermore, since the certificate is secure and unique, there's no need for the user to supply a password. The user can be authenticated with no additional effort on their part, all without sacrificing detailed auditing or method-level authorization. This is a big step toward user-friendliness.
The downside
The downside of digital certificates is that they are difficult to install. Most users are unwilling to download and install a digital certificate just to surf a Web site, so this limits certificates’ feasibility in certain situations, such as B2B communications and secure intranets. Digital certificates also limit the user to a single machine. Even if I install a certificate on my work computer, I have to install a second one before I can access the Web service from my home computer. Finally, certificates never obtain input from the user for authentication purposes: You are only authenticating the machine, not the person using the machine. If someone else sits at my desk, the Web service will assume that I am using the service.
Looking ahead
In the final installment of this series, we will compare all three techniques for securing paid Web services side by side, as well as examine some additional techniques for providing general Web service security.