HTTP authentication

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

• HTTP basic authentication
• SOAP on Secure Sockets Layer (SSL) with HTTP basic authentication
• SOAP on SSL with SOAP signature

HTTP authentication

Many applications require users to provide identifying information. You can restrict access to data based on the authorization level assigned to users.

The Apache implementation of SOAP has an API to set the user ID/password for HTTP basic authentication.

SOAP on Secure Sockets Layer (SSL) with HTTP basic authentication

The SOAP on SSL scenario is useful for many business-to-business applications because:

• The data in transit is protected from eavesdropping or forgery by SSL
• The server identity is guaranteed by SSL server authentication
• The client identity is authenticated through user ID 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 these two SOAP service entries:

• https://a_company.com/inventory/inquiry
• https://a_company.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 that anyone can inquire about the inventory but only the inventory clerks can update the contents.

Perform these steps to enable the SOAP on SSL scenario:

1. Configure the web server (httpd.conf) so that it only allows SSL access to these servlets.
2. 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 (user ID/password).

In this case, the 'update' application does not know the identity of the requester; it only knows that access is granted.

SOAP on SSL with SOAP signature

Applications might need nonrepudiable 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 through a secure channel. The following service is deployed with a signature verification function: https://a_company.com/partorder.

Configure signature verification with this 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://a_company.com/partorder service, the service requester should sign her or 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:

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

The <ds:KeyInfo> template controls:

• 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.