InfoCenter Home >
4: Developing applications >
4.8: Web services - an overview >
4.8.4: Securing SOAP services

4.8.4: Securing SOAP services

Since the SOAP specification left security issues open, several proposals evolved to bridge the security gaps. Recently the SOAP Security Extension [SOAP-SEC] was published as a W3C Note, specifically addressing the XML Digital Signature.

The SOAP security extension, included with WebSphere Application Server Version 4.0, is a security architecture based on the SOAP security specification, and widely-accepted security technologies such as Secure Sockets Layer or SSL.

There are three options for security when using HTTP as the transport protocol.

Application developers are free to combine these security options according to their security requirements. The following scenarios describe the implementation of the security options.

HTTP basic authentication

Many applications require users to provide identifying information. You cannot provide access control for individual services. You can only provide access control for the router servlets (as for example the rpcrouter servlet URI). If a user can get to a servlet, he can access any of the Web services served through the servlet. Therefore, if you have a set of "secure" services and "unprotected" services, you have to partition them differently so that "secure" services are accessed through an URI that is secured (for example, /secureRPCRouter) and the unprotected services are open for everyone to access (for example, /uprotectedRCPRouter).

Using the Application Assembly tool, you can set authorization levels by assigning roles to HTTP methods and by assigning users to roles. You can then authenticate users, verifying they are authorized to view specific information. There are many ways to prompt users for authentication data. See articles Overview: Using programmatic and custom login and The WebSphere authorization model for more information on different authentication methods, and on role-based authorization scenarios.

SOAP on SSL with HTTP basic authentication

To make a request over HTTPS, using the SSL support of Apache SOAP, you need a separate Java Secure Socket Extension (JSSE) provider.

WebSphere Application Server includes the ibmjsse.jar in the JDK extensions.

The "SOAP on SSL" scenario is useful for many business-to-business (B2B) applications because:

  • The data in transit is protected from eavesdropping or forgery by SSL.
  • The client identity is authenticated through userid and password, which are encrypted by the SSL transport.

For example, if an inventory application is configured as a Web service, the service provider has the following two SOAP service entries:

  • https://foo.com/inventory/inquiry
  • https://foo.com/inventory/update
Each SOAP service entry should be deployed as a separate enterprise application (EAR) because each service has a different access control policy, which is:   anyone can inquire about the inventory but only the inventory clerks can update the contents.

The SOAP enablement model limits you to one context root for the unsecured services and another for the secured services. In this example, you want to make the inquiry service unsecured and the update service secured. If you want different levels of security for a "secured" service, then you must deploy the entries in the "secured" service as separate EAR files.

Do the following to enable the "SOAP on SSL" scenario:

  • Configure the web server (httpd.conf) so that it only allows SSL access to these servlets.
  • Configure the security role for the RPCRouterServlet in the inquiry services EAR so that the RPCRouterServlet for the 'inquiry' service is accessible by everyone, while the RPCRouterServlet for the 'update' service requires authentication based on the HTTP basic authentication (userid/pasword).
In this case, the 'update' application does not know the identity of the requester; it only knows that access is granted. In other words, the "update" application is not concerned with the identity of the user because it knows WebSphere Application Server is ensuring that only authenticated users have access.

SOAP on SSL with SOAP Signature

Applications might need non-repudiable proof of exchanged messages. One example is a web service that accepts part orders. The business partners establish a form of trust relationship based on public keys. This can be done using the public key infrastructure (PKI) through a third party certificate authority (CA), or by exchanging public keys with a secure channel. The following service is deployed with a signature verification function:

https://foo.com/partorder
Configure signature verification with the following information:
  • Scope of signature (indicates the portion of the SOAP envelope that must be authenticated. The default is the content of SOAP-ENV:Body).
  • Trusted keys or trusted root keys.
  • Default key to verify signature if no KeyInfo is specified.
  • Other policies regarding signature validation.
  • Behavior when signature verification fails.
  • Additional requirements on signature (as for example, specific requirements on hash/C14N algorithms to be used, timestamp validity, and so forth).

If the signature is missing or if signature verification fails, the signature verification function can be configured so that the servlet returns a SOAP fault.

To send part orders to the https://foo.com/partorder service, the service requester should sign his SOAP messages with a signature component. The signature component is initialized using two templates:

  1. <ds:SignedInfo> template
  2. <ds:KeyInfo> template

The <ds:SignedInfo> template controls the following:

  • What parts of the SOAP envelope must be signed
  • What algorithms (canonicalization, transformation, digest, sign) should be used

The <ds:KeyInfo> template controls the following:

  • Whether or not to include the entire certificate chain in <ds:KeyInfo>
  • Decision to include only certificate and serial number
  • Public key value
  • Decision to provide no key information (so that the default key must be used for verification).

You can combine the service request with HTTP basic authentication, if necessary.

Go to previous article: Quick reference of Web services resources Go to next article: Running the security samples

 

 
Go to previous article: Quick reference of Web services resources Go to next article: Running the security samples