In a WS-Security scenario, the message flows are as shown in the following
figure:
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.
Deprecation note: The
WS-Security Draft 13 specification is deprecated in WebSphere Application
Server Version 6, so you should only use this specification to enable inter-operation
between applications running in WebSphere Application Server Version 5 and
Version 6, 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 on the history of the WS-Security Draft 13 specification, see
Web services security specification
for Version 6 and later - a chronology.