InfoCenter Home > 4.8.4: Securing SOAP servicesSince 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 authenticationMany 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 authenticationTo 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:
For example, if an inventory application is configured as a Web service, the service provider has the following two SOAP service entries:
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:
SOAP on SSL with SOAP SignatureApplications 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/partorderConfigure signature verification with the following information:
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:
The <ds:SignedInfo> template controls the following:
The <ds:KeyInfo> template controls the following:
You can combine the service request with HTTP basic authentication, if necessary. |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|