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:
- 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 you configure for them.
To protect an inbound or outbound service, you 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 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:
- 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 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.
Note: Use of WS-Security Draft 13 was deprecated
in
WebSphere® Application Server Version 6.0. You should only use Draft 13 bindings to enable interoperation between applications running in
WebSphere Application Server Version 5.1 and Version 7.0, or to allow continued use of an existing web services client application that is 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.