Service integration technologies and WS-Security
In a WS-Security scenario, the message flows are as shown in the following figure:
Figure 1. Message flows
The client generates a request that is handled by the client Web services engine. This engine reads the client security configuration and applies the security defined in the ibm-webservicesclient-ext.xmi file to the SOAP message. The engine gets additional binding information from the ibm-webservicesclient-bnd.xmi file (for example, the location of a keystore on the file system).
On receipt of a SOAP message, the web services engine on the server refers to the *.xmi files for the called web service. In this case, the ibm-webservices-ext.xmi file tells the engine what security the incoming message must have (for example, that the body of the message must be signed). If the message does not comply, it is rejected. The web services engine verifies any security information then passes the message on to the web service called.
On the response from server to client, the process is reversed. The web service *.xmi files tell the web services engine what security to apply to the response message, and the client *.xmi files tell the client engine what security to require in the response message.
If we apply this scenario to inbound and outbound services, the message flows are as shown in the following figure:
In this scenario:
- The client application and the target web service have the security settings in their *.xmi files. You get this information from the owning parties.
- The inbound service and outbound service have the security settings that we configure for them.
To protect an inbound or outbound service, we apply the following types of WS-Security resource to the ports that the service uses:
- WS-Security configurations
- WS-Security bindings
where the configurations resource type specifies the level of security that you require (for example "The body must be signed"), and the bindings resource type provides the information that the run-time environment needs to implement the configuration (for example "To sign the body, use this key").
WS-Security resources are administered independently from any Web service that uses them, so we can create a binding or configuration resource then apply it to many web services. However, the security requirements for an inbound service (which acts as a target web service) are significantly different from those required for an outbound service (which acts as a client). Consequently, Each WS-Security resource type is further divided into sub-types. When we create a new configuration resource, the type of configuration resource chosen to create depends on whether the configuration applies to inbound services or outbound services. When we create a new binding resource, the type of binding resource chosen to create depends on the context in which the binding is used:
- A binding for use when consuming requests from a client to an inbound service.
- A binding for use when generating requests from an outbound service to a target web service.
- A binding for use when consuming responses from a target web service to an outbound service.
- A binding for use when generating responses from an inbound service to a client.
When we create WS-Security resources, you also choose between creating resources that comply with the Web Services Security (WS-Security) 1.0 specification, and creating resources that comply with the WS-Security Draft 13 specification.
Use of WS-Security Draft 13 was deprecated in WebSphere Application Server v6.0. Use of WS-Security Draft 13 is deprecated, and should only be used to allow continued use of an existing web services client application written to the WS-Security Draft 13 specification. For more information about the history of the WS-Security Draft 13 specification, see Web Services Security specification - a chronology.