This is the final installment in an article series examining techniques to architect secure Web services. The first installment set up two fictional companies, one to provide a Web service and one to consume it, and examined the first security technique, IP blocking. The second installment looked at two additional techniques, user authentication, and digital certificates. This article compares the techniques.
Check out the previous articles in this series:
- “Secure Web services with IP blocking”
- “Secure Web services with user authentication and digital certificates”
Comparison
Table A summarizes the relative strengths and weaknesses of each security technique with respect to a number of development goals. (Lower numbers are better.)
Table A
|
XML security technique strengths and weaknesses
As you can see, each of the three security techniques has its own strengths and weaknesses. As is usually the case, the ease of development of IP blocking comes at the expense of flexibility. IP blocking is simple and quick to implement and requires no effort on the part of the end user. The cost for this simplicity is that IP blocking allows only Web-site-level authorization and blocks users from accessing other parts of the Web site. Another price exacted by the ease of development of IP blocking scenarios is nonuser-friendly error messages. Because authentication/authorization occurs at the server level, users blocked from accessing a Web service will see a Web server error message (HTTP 403.6) rather than a customized, user-friendly message. This can be frustrating to users and detrimental to repeat business.
User authentication, on the other hand, is much more flexible, allowing you to create method-level authorization. This technique also allows users to access the Web service from any location and does not block unauthorized users from other resources in the Web site. Furthermore, blocked users can receive customized error messages indicating the reason their access is blocked, such as “invalid user name.” Because the authentication/authorization is happening at the method level, this technique also allows much more detailed audit tracking. Each Web method can store information about when and how it is accessed. However, this flexibility comes with a high development and potentially high end-user cost. The developer must design and implement a solution for storing sensitive usernames and passwords as well as mitigate the security risks associated with storing this information. At the same time, user authentication puts more of a burden on the end user, forcing developers to enter additional parameters in their code and potentially forcing a consumer accessing the Web service directly to enter his or her username and password many times.
Digital certificates fall somewhere between IP blocking and user authentication in terms of ease of development and flexibility. Because code to verify the digital certificate is required at the method level, this technique provides the same flexibility as user authentication, allowing developers to create complex authorization schemes and user-friendly error messages for users. Like user authentication, this technique also allows a high level of audit tracking detail. Certificates can contain information about the user, so they can be more user-friendly by eliminating the need for the end user to enter his or her username or password for every method. As appealing as these benefits are, they come at a very high cost: difficult user installation. A digital certificate must be installed on every client machine, and the installation process can be difficult. This cost would be too high for situations where the general public should be allowed to consume a Web service.
Level of security
Obviously, a final concern that must be considered for each of these techniques is the level of security it provides. Although IP blocking may, at first blush, seem the most secure because it blocks access to the entire site, it is probably the easiest to intentionally thwart. One of the first tricks hackers learn is how to imitate, or spoof, a specified IP address. For example, it would be trivial for a hacker to determine the IP address of RegalResearch.com and then spoof that IP address to gain access to The Internet Dictionary Company (TIDC) Web service. This concern is complicated by the fact that IP blocking does not offer detailed audit tracking; it would be difficult to determine when and how a hacker was illegally accessing the TIDC service.
User authentication ranks a little better than IP blocking on the security meter, primarily because of users’ reluctance to use passwords that are difficult to guess. Typical consumers will use the same username and password combination on many different systems; if one is compromised, they are all compromised. Typical users also prefer easy-to-remember passwords such as their birthday or spouse’s name. These are typically easy for would-be hackers to guess. Also, because most passwords are short string values, it is relatively easy for a determined hacker to test all possible password combinations if they know the general parameters of the password.
Digital certificates weigh in as the heavyweight for security due to the fact that they are unique per user, encrypted with industry-standard techniques, and hard to duplicate. Digital certificates are an excellent choice for situations where the maximum amount of security is needed, such as secure intranets.
Conclusion
Now that we’ve examined three techniques for securing our Web service from unauthorized users, let’s check in with our fictional company and see what they would choose. First, TIDC wants to ensure the highest level of security against unauthorized use and detailed tracking of usage. Customers are charged per method use, so it is very important to ensure that every call is accurately tracked and charged for. The security need favors digital certificates or IP blocking, but the audit tracking need favors user authentication or digital certificates.
That’s two votes for digital certificates, so TIDC now considers two potential problems with using this technique:
- Digital certificates are difficult to install. However, this is not a problem for TIDC. TIDC plans to have only a single customer initially (Regal Research) and does not realistically plan to add more than a couple of new customers each month. Thus, TIDC can commit the necessary personnel to help get new clients set up with a digital certificate.
- Digital certificates must be installed on every machine that will access the Web service. Because Regal Research is run from a single Web server, it will only need to install a single certificate. New certificates will only have to be installed if Regal Research moves to a Web farm configuration. RegalResearch.com end users will not have to install a certificate.
By considering all the options and weighing pros and cons, TIDC has determined that digital certificates are the best solution for securing the company’s Web service.
