Network Deployment (Distributed operating systems), v8.0 > Applications > Web services > Bus-enabled web services


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 that is 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 that is 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 you apply this scenario to inbound and outbound services, the message flows are as shown in the following figure:

In this scenario:

To protect an inbound or outbound service, you apply the following types of WS-Security resource to the ports that the service uses:

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 you 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 you create a new configuration resource, the type of configuration resource that you choose to create depends on whether the configuration applies to inbound services or outbound services. When you create a new binding resource, the type of binding resource that you choose to create depends on the context in which the binding is used:

When you 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 WAS v6.0. Use of WS-Security Draft 13 is deprecated, and you should only use it to allow continued use of an existing web services client application that has been 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.
Configure secure transmission of SOAP messages by using WS-Security
Get WS-Security information from the owning parties Concept topic

+

Search Tips   |   Advanced Search