Web services security enhancements

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.

Identity assertion trust validation

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.

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.

Important: The distributed nonce caching feature uses the WebSphere Application Server data replication service (DRS). The data in the local cache is pushed to the cache in other servers in the same replication domain. The replication is an out-of-process call and, in some cases, is a remote call. Therefore, there is a possible delay in replication while the content of the cache in each application server within the cluster is updated. The delay might be due to network traffic, network workload, machine workload, and so on.

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 cell level:
  • Click Security > Web services.
  • 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.
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.



Related concepts
Collection certificate store
Certificate revocation list
Nonce, a randomly generated token
Assembly tools
What is new for securing Web services
Concept topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 10:43:27 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=v602web&product=was-nd-mp&topic=cwbs_wssv6enhance
File name: cwbs_wssv6enhance.html