Design Time

In earlier chapters, we learned that SOAP is a basic message format that has two parts, the header and body. The header contains metadata associated with the request, and the body is used for holding basic data associated with the message. The simple fact of sending metadata with the message should scare most security-conscious people. Identifying the person sending the message is important to any security approach. Security for financial, medical, and other secure transactions usually requires a certificate, Kerberos ticket, or similar mechanisms.

One approach is to create a credentials header that contains an unlimited number of credentials. Inclusion of multiple credentials can be used for more than just authentication. As an example, you could include the certificate that holds the public key used to encrypt a session key. Other certificates can be included that specify the certificate authority chain for another included certificate. Later in this chapter, we drill down into WS_Security—one specification that allows for creating SOAP security headers.

Deployment Time

Whether you decide to use a UDDI- or ebXML-based registry, you will most likely have many of the following security concerns:

• Is the information in the registry up to date?

• How can you ensure that data in the registry was placed there by a valid publisher?

• How can you ensure that only legitimate publishers can add information to the registry?

• How does a registry publisher restrict access to specific registry readers?

• How does a registry provide selective access to partners that need usage data?

• How are credentials (authentication and authorization) transferred to federated registries?

• How can you bind the registry's security mechanism to the security infrastructure of a particular organization?

If the service you want to expose requires security, and access is limited to selected parties, the first step should be to consider avoiding altogether putting it in the registry. Other alternatives may include running the UDDI/ebXML service on a nondefault TCP/IP port. If you know in advance which computers need to access your Web service, you can take advantage of firewall security or Internet Protocol Security (IPSec) to further restrict access. IPSec allows you to establish secure communication between two servers and is a feature provided at the network layer by many operating systems. This approach works well for private networks but may be harder to implement if your Web service will be exposed to the Internet.

Run-time

A Web server and application server in a Web services infrastructure are typically distributed for additional security. A well-thought-out security plan will use the security authentication features built into the Web server tier. The three popular Web server platforms (Apache, IIS, and Sun ONE Web Server) all support several authentication mechanisms for HTTP. Table 15.1 shows five standards-based mechanisms that can be used at the Web server tier to secure your service.

Table 15.1: Authentication Methods

Authentication method	Description	Limitation
Basic	Allows for the basic identification of a Web services client based on an ID and password	The ID and password are sent in plain text that could allow credential stealing.
Basic over SSL	Same as basic, but ID and password are sent over the network using Secure Sockets Layer (SSL) encryption instead of plain text.	SSL is a good choice for Internet-based Web services but requires more CPU usage than simple basic authentication. This can be offset in large infrastructures by hardware-based devices for SSL processing.
Kerberos	A Web services client is issued a ticket for access to each Web service it is authorized to use.	This is the most secure approach but can be used only with intranets. Kerberos cannot be used with clients accessing a Web service through a proxy server or a firewall that does Network Address Translation.
Client certificates	Digital certificates can be used to validate the identity of a client and for signing and nonrepudiation.	Each client is required to obtain a certificate, which has a significant cost. Although server certificates have been used for a long time, client certificates are not widely used.
Digest	Uses hashing algorithms to transmit client credentials securely.	Relatively new standard, so it may require upgrading to the latest versions of Web server software.

Secure Sockets Layer (SSL) (Figure 15.1) will be the method that secures most Web services. It has become the de facto standard to encrypt data transmitted between HTTP requesters (usually Web browsers) and HTTP servers (Web servers). Secure Sockets Layer operates at the session layer of the OSI stack and provides point-to-point confidentiality and either one-way or two-way authentication. Establishing a secure session involves the following steps:

1. The server is registered with a certificate authority (e.g., VeriSign, Thawte) and is assigned a unique certificate.

2. The server transmits its public key to the client.

3. The requestor takes the public key and uses it to encrypt a random number generated by the client (known as a premaster secret). The server will decrypt the premaster secret using its private key.

4. The server creates a new session key based on the premaster secret. The key can be decrypted and used only by the requestor that generated the premaster secret.

The actions taken by the server and requestor to create a session where all traffic between the two is encrypted allows the service to handle authentication, confidentiality, and integrity. SSL in its de facto implementation does not always provide a suitable method for authentication. Most SSL deployment uses server-side certificates, in which the client obtains a copy of the server's certificate, allowing it to authenticate the server and create an encrypted channel. This is the typical model in an e-commerce Web site, because of its ease of implementation and low risk. The main risk in this situation is that a third party may acquire credit-card or other personal information.

SSL will be used for initial Web services security until the proper security schemes are fully developed. In a Web service, SOAP can expose functionality that goes beyond simple low-risk transactions. Therefore, it may be important to also authenticate the requestors in addition to the servers, unlike the typical B2C scenario. SSL also does not protect a Web service against traditional forms of attack, such as buffer overviews. A hacker could create a buffer overview attack by sending parameters that are longer than the Web service expects. A hack could also create a replay attack by playing back a message twice to impersonate the sender.

Transports that use SSL or similar mechanisms help ensure the confidentiality of a message in flight but cannot provide secure end-to-end communication, because they can secure communication only to the next hop. A message may sometimes travel through untrusted links or use communication that cannot be secure. The only way to truly have end-to-end security is by incorporating it at the application level.

Incorporating security into an application is difficult for all but the best architects who have a detailed understanding of cryptographic technologies. Incorporating algorithms into an application itself may actually increase an organization's security exposure if used incorrectly. The most attractive architecture would use an approach where security was close to the application but not incorporated into it. Adding security to the message level is the best solution for Web services.

Skilled Java developers can develop custom authentication mechanisms, so there may be merit in exploring the development of your own. To do so, define your Web service so that client credentials are passed in the SOAP header. Alternatively, credentials can be passed as elements in the message body. The Web service would retrieve the credentials from the message and pass it to a custom authentication handler. The logic could compare the credentials to an LDAP server, relational database, or other data stores.

In the Chapter 10, we learned how to expose services with and without Secure Sockets Layer (SSL). Using what we have learned so far, we could define a custom login authentication operation for our Web services that could return a session key. This, of course, is best done over SSL, to prevent hijacking. The communication between the Web services client and server could occur normally over HTTP. The client would include the session identifier in the SOAP header.

This approach would allow for efficient use of server resources and provide a moderate level of security. It does run the risk that the session key could be hijacked but limits exposure that would allow the client's password to be stolen. Alternatively, you could use both SSL and the session key approach for maximum security.

Trust integration is the most difficult of all security principles to implement in Web services architecture. A trust service is typically implemented as a Web service that other Web services call to enable trust for their own transactions. Trust services provide the security functions (e.g., encryption, signing, time-stamping, administrative) to other Web services that require a guarantee of their transactions. This approach allows for developers and architects to avoid having to learn the complexity of public-key initiatives and requires only that they invoke the appropriate trust service at the right time.

Trust services as part of your Web services architecture will also allow you to outsource many of your security functions. If you needed to calculate the digital signature for an XML service response, the calculation could be outsourced to a digital signature trust service. One standard that will be included in many trust services is the XML Key Management Specification (XKMS). It is not responsible for encryption or signing and handles only key registration and validation functionality.