WebSphere Application Server Versions 6 and later include a number
of enhancements for securing Web services.
Building your applications
The Web services security
runtime implementation that is used only by WebSphere Application Server is
based on the IBM Web Service runtime. In turn, the IBM Web services runtime
is based on the open source Axis Web Service engine with IBM enhancements.
The application programming model is JAX-RPC (JSR-109). The open source Axis
Web Service engine uses DOM as the document object model.
To assemble
your applications and to specify the security constraints for Web services
security in the deployment descriptor and bindings, it is recommended that
you use an assembly tool.
You can also use the WebSphere Application Server administrative console to
edit the application binding file.
Using
identity assertion
In a secured environment such as an intranet,
a secure sockets layer (SSL) connection or through a Virtual Private Network
(VPN), it is useful to send the requester identity only without credentials,
such as password, with other trusted credentials, such as the server identity.
WebSphere Application Server supports the following types of identity assertions:
- A username token without a password
- An X.509 Token for a X.509 certificate
For the X.509 certificate, WebSphere Application Server uses the
distinguished name in the certificate as a requester identity. There are two
trust modes for validating the trust of the upstream server:
- Basic authentication (username token)
- The upstream server sends a username token with a user name and password
to a downstream server. The consumer or receiver of the message authenticates
the username token and validates the trust based upon the TrustedIDEvaluator
implementation. The TrustedIDEvaluator implementation must implement the com.ibm.wsspi.wssecurity.id.TrustedIDEvaluator
Java interface.
- Signature
- The upstream server signs the message, which can be any message part such
as the SOAP body. The upstream server sends the X.509 token to a downstream
server. The consumer or receiver of the message verifies the signature and
validates the X.509 token. The identity or the distinguished name from the
X.509 token that is used in the digital signature is validated based on the
TrustedIDEvaluator implementation. The TrustedIDEvaluator implementation must
implement the com.ibm.wsspi.wssecurity.id.TrustedIDEvaluator Java interface.
The following figure demonstrates the identity assertion
trust process.

In this figure, server s1 is
the upstream server and identity assertion is set up between server s1 and
server s2. The s1 server authenticates the identity called bob.
Server s1 wants to send bob to the s2 server with
a password. The trust mode is an s1 credential that contains the
identity and a password. Server s2 receives the request, authenticates
the user using a Java Authentication and Authorization Service (JAAS) login
module, and uses the trusted ID evaluator to determine whether to trust the
identity. If the identity is trusted, bob is used as the caller that
invokes the service. If authorization is required, bob is the identity
that is used for authorization verification.
In WebSphere Application
Server Version 6 and later, the identity can be asserted as the RunAs (invocation)
identity of the current security context. For example, the Web services gateway
authenticates a requester using a secure method such as password authentication
and then sends the requester identity only to a back-end server. You might
also use identity assertion for interoperability with another Web services
security implementation.
Using
the pluggable token framework
The OASIS Web Services Security specification
defines a generic mechanism to associate security tokens with a SOAP message.
In WebSphere Application Server, the pluggable token framework is enhanced
to handle this flexible mechanism. The following figure shows this pluggable
framework.

The following terms are used in the previous figure:
- TokenGenerator
- The token generator, or the com.ibm.wsspi.wssecurity.token.TokenGeneratorComponent
Java interface, is responsible for the following actions:
- Marshalling the token into the correct XML representation for the SOAP
message. In this case, marshalling is the process of converting a token to
a standardized format before transmitting it over the network.
- Setting the token to the local JAAS Subject.
- Generating the correct token identifier based on the key information type.
The token generator invokes the CallbackHandler or the javax.security.auth.callback.CallbackHandler
Java interface for token acquisition. The javax.security.auth.callback.Callback
Java interface is used to pass information from the callback handler to the
token generator.
- CallbackHandler
- The callback handler, or the javax.security.auth.callback.CallbackHandler
Java interface, is responsible for acquiring the token using a method such
as GUI prompt, a standard-in prompt, talking to external token service, and
so on.
- TokenConsumer
- The token consumer, or the com.ibm.wsspi.wssecurity.token.TokenConsumerComponent
Java interface, is responsible for the following actions:
- Unmarshalling the token from the XML format within the SOAP message. In
this case, unmarshalling is the process of converting the token from
the standard network format to the local or native format.
- Calling the JAAS login configuration to validate the token
- Setting the correct WSSToken, or com.ibm.wsspi.wssecurity.auth.token.WSSToken
Java abstract class, to the local JAAS Subject.
At the final stage of Web services security processing, the local JAAS
Subject content is used to create the WebSphere credentials and principals.
The Caller Subject is created based on the content of the local JAAS Subject.
- JAAS login configuration
- The JAAS login configuration is responsible for validating the token.
The validation process might involve making a call to the WebSphere Application
Server authentication module or calling a third-party token service.
Signing
or encrypting data with a custom token
The key locator, or the com.ibm.wsspi.wssecurity.keyinfo.KeyLocator
Java interface, is enhanced to support the flexibility of the specification.
The key locator is responsible for locating the key. The local JAAS Subject
is passed into the KeyLocator.getKey() method in the context. The key locator
implementation can derive the key from the token, which is created by the
token generator or the token consumer, to sign a message, to verify the signature
within a message, to encrypt a message, or to decrypt a message.
Important: The com.ibm.wsspi.wssecurity.keyinfo.KeyLocator Java interface
is different from the version in WebSphere Application Server Version 5.x.
The com.ibm.wsspi.wssecurity.config.KeyLocator interface from Version 5.x is
deprecated. There is no automatic migration for the key locator from Version
5.x to Versions 6 and later. You must migrate the source code for the
Version 5.x key locator implementation to the key locator programming
model for Version 6 and later.
Signing
or encrypting any XML element
The deployment descriptor supports
the XPath expression for selecting which XML element to sign or encrypt. However,
an envelope signature is used when you sign the SOAP envelope, SOAP header,
or Web services security header.
Supporting LTPA
Lightweight
Third Party Authentication (LTPA) is supported as a binary security token
in Web services security. The token type is http://www.ibm.com/websphere/appserver/tokentype/5.0.2/LTPA.
Extending the support for timestamps
You
can insert a timestamp in other elements during the signing process besides
the Web services security header. This timestamp provides a mechanism for
adding a time limit to an element. This support is an extension for WebSphere
Application Server. Other vendor implementations might not have the ability
to consume a message that is generated with an additional timestamp that is
inserted in the message.
Extending the support for nonce
You
can insert a nonce, which is a randomly generated value, in other elements
beside the Username token. The nonce is used to reduce the chance of a replay
attack. This support is an extension for WebSphere Application Server. Other
vendor implementations might not have the ability to consume messages with
a nonce that is inserted into elements other than a Username token.
Supporting distributed nonce caching
Distributed
nonce caching is a new feature for Web services in WebSphere Application Server
Versions 6 and later that enables you to replicate nonce data between servers
in a cluster. For example, you might have application server A and application
server B in cluster C. If application server A accepts a nonce with a value
of X, then application server B creates a SoapSecurityException if
it receives the nonce with the same value within a specified period of time.
For
more information, see the information that explains nonce cache timeout, nonce
maximum age and nonce clock skew in Web services: Default bindings for the Web services security collection. However, if application server B receives another
nonce with a value of Y, then it does not throw an exception, but
caches the nonce and copies it into the other application servers within the
same cluster.
Caching the X.509 certificate
WebSphere
Application Server Version 6 and later cache the X.509 certificates it receives,
by default, to avoid certificate path validation and improve its performance.
However, this change might lead to security exposure. You can disable X.509
certificate caching by using the following steps:
On the server level:
- Click Servers > Application servers > server_name .
- Under Security, click Web services: Default bindings for Web services
security.
- Under Additional properties, click Properties > New.
- In the Property name field, type com.ibm.ws.wssecurity.config.token.certificate.useCache.
- In the Property value field, type false.
Providing support for a certificate
revocation list
The certificate revocation list (CRL) in WebSphere
Application Server Version 6 and later is used to enhance certificate path
validation. You can specify a CRL in the collection certificate store for
validation. You can also encode a CRL in an X.509 token using PKCS#7 encoding.
However, WebSphere Application Server Version 6 and later do not support X509PKIPathv1
CRL encoding in a X.509 token.
Important: The PKCS#7 encoding was
tested with the IBM certificate path (IBM CertPath) provider only. The encoding
is not supported for other certificate path providers.