HTTPS for Implementing Web Services Security
Give detailed attention to the server and client configurations for successful deployment of Web services with transport-layer security
by Jim Clune
Posted August 25, 2003
Now that IT managers and hackers are well aware of the security risks inherent in Web services, it is increasingly important for Web services developers to know how to implement security schemes. However, because much of the media is focused on high-level discussions of emerging message-layer security technologies such as WS-Security, XML signatures, XML encryption, and Security Assertion Markup Language (SAML), it can be difficult to grasp practical security fundamentals and devise a step-by-step plan for solving whatever type of security problem you have been asked to handle.
Therefore, let's take a look at the nuts and bolts of implementing and deploying a Web service with HTTPS, an extension of HTTP that uses transport-layer security by layering HTTP on top of Secure Sockets Layer (SSL). Although the transport-layer security topic is not currently as hot as message-layer security, it does have several important virtues. It is a mature technology, so both standards and tools have already been developed. It also provides a good transition path for engineers who are somewhat familiar with transport-level security but are new to Web services.
To make the discussion as concrete and pragmatic as possible, I will walk you through a sample HTTPS implementation. The example I use will be a service written in Java and deployed with Apache Axis 1.0 (Apache's second-generation SOAP implementation) and Apache Jakarta Tomcat 4.1.12 as the servlet container and HTTP server. Each of these tools is available at no cost for commercial and noncommercial use. Some of the details covered will be necessarily specific to these tools and technologies, but the principles discussed are equally applicable to other Web services technologies, such as Microsoft's .Net.
HTTPS provides encryption, which ensures privacy and message integrity. HTTPS also authenticates through the use of certificates, which can be used on the server side, the client side, or both. HTTPS with server-side certificates is the most common configuration on the Web today. In this configuration, clients can authenticate servers, but servers cannot authenticate clients. However, HTTPS can also be used in conjunction with basic or digest authentication, which provides a weaker form of authentication for clients. When deploying a Web service with HTTPS, it is important to determine the authentication requirements as early as possible. These requirements will determine where you use certificates and what, if any, auxiliary authentication mechanism you might want on the client side.
To illustrate the deployment of SOAP services over HTTPS, I'll use the example of a financial institution interested in providing Web services for business-to-business integration with its business partners. Before jumping into the security issues, let's take a brief look at the parts of the Web service that are relevant to the sample security implementation.
Automatic WSDL
Assume that this financial institution wants to expose the simple method getAccountBalance(accountNumber), which takes an account number as an input and returns the current account balance. The Java method signature may look like this:
public float getAccountBalance(
int accountNumber) throws
InvalidAccountException {
// Perform database query and
// return result.
...
}
This Java method signature defines the interface for a Java application, but language-specific interfaces are insufficient for interoperable Web services. The standard approach is to create a Web Services Description Language (WSDL) document. This WSDL then becomes the published interface to business partners utilizing the service. When WSDLs were first introduced, they were written by hand, and that is still a viable option. However, the more recent approach is to use tools that generate WSDLs automatically. Axis provides a mechanism for this, as does Microsoft's .Net. To deploy the implementation, you need to configure the components (in this case, Tomcat, Axis, and the implementation Java class) to work together. The Axis documentation explains all the details, but the main step is to copy the axis directory from your Axis installation to the webapps subdirectory of your Tomcat installation. When Tomcat is restarted, it reads the Web Application description stored as webapps/axis/WEB-INF/web.xml and then uses that information to find the AxisServlet.
You can deploy services to Axis in a number of ways, but the simplest approach is to copy your Java source as a JWS file to the webapps/axis directory. By using the JWS extension, you indicate to Axis that this file is a Java Web service and allow this file to be processed with an on-demand compilation process similar to that used for JSP files.
For this particular example, you copy a file named Account.jws to the webapps/axis directory. You can then see the dynamically generated WSDL document by pointing a browser to http://localhost:8080/axis/Account.jws?wsdl.
In the next installment, we'll look at server-side configuration for deploying this Web service over HTTPS.
About the Author
Jim Clune is a development manager for ParaSoft who supervises the development of error prevention and error detection tools for C, C++, and Web development. He began his career at ParaSoft in 1997 as a quality consultant and was quickly promoted to software engineer where he had a hands-on influence on the development of ParaSoft's products. He holds a BS in engineering from Harvey Mudd College and an MS in applied computer science and technology with an emphasis in technical programming from Azusa Pacific University. Clune is well versed in Windows, UNIX (including Linux), and Mac systems. He specializes in C/C++, Visual Basic AML, and PLC ladder logic languages.
Back to top
|