+

Search Tips   |   Advanced Search

WS-Security enhancements


Overview

WAS includes a number of enhancements for securing Web services, including policy sets supported in WAS V6.1 Feature Pack for Web Services, and later.

The WS-Security run time implementation used by WAS V7 is based on the JAX-WS model, which is based on Apache Open Source Axis2, and the data model is AXIOM. Instead of deployment descriptor and bindings, a policy set is used for configuration. Use the admin console to edit the application binding files associated with the policy sets. The JAX-WS run time is supported for the WAS V6.1 Feature Pack for Web Services, and later.

The JAX-RPC model, which uses deployment descriptors and bindings, is still supported.

 

Policy sets

Policy sets can only be used with JAX-WS applications, in WAS V6.1 Feature Pack for Web Services, and later. Policy sets cannot be used for JAX-RPC applications.

Policy sets combine settings, including those for transport and message level configuration, such as...

 

Manage trust policies

WS-Trust provides the ability for an endpoint to issue a security context token for WS-SecureConversation. The token issuing support is limited to the security context token. Trust policy management defines a policy for each of the trust service operations, such as issuing, cancelling, validating, and renewing a token. A client's bootstrap policies must correspond to the WAS trust service policies.

 

Secure session-based messages

Web Services Secure Conversation provides a secured session for long running message exchanges and leveraging symmetric cryptographic algorithm. WS-SecureConversation provides the basic security for securing session-based messages exchange patterns, such as WS-Security Reliable Messaging (WS-ReliableMessaging).

 

Updating message-level security

WS-Security V1.1 supports the following functions that update the message-level security.

Signature confirmation enhances the protection of XML digital signature security. The <SignatureConfirmation> element indicates that the responder has processed the signature in the request, and the signature confirmation ensures that the signature is indeed processed by the intended recipient. To process signature confirmation correctly, the initiator must preserve the signatures during the request generation processing and later must retrieve the signatures for confirmation checks even with the stateless nature of Web Service and the different message exchange patterns. You enable signature confirmation by configuring the policy.

The encrypted header element provides a standard way of encrypting SOAP headers, which helps inter-operability. As defined in the SOAP message security specification, the <EncryptedHeader> element indicates that a specific SOAP header (or set of headers) must be protected. Encrypting SOAP headers and parts helps to provide more secure message-level security. The EncryptedHeader element ensures compliance with the SOAP mustUnderstand processing guidelines and prevents disclosure of information contained in attributes on a SOAP header block.

 

Use 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. WAS supports the following types of identity assertions:

See about identity assertion, read the topic Trusted ID evaluator.

 

Signing or encrypting data with a custom token

For the JAX-RPC model, 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. The com.ibm.wsspi.wssecurity.keyinfo.KeyLocator Java interface is different from the version in WAS V 5.x. The com.ibm.wsspi.wssecurity.config.KeyLocator interface from V 5.x is deprecated. There is no automatic migration for the key locator from Version 5.x to Vs 6 and later. You must migrate the source code for the V5.x key locator implementation to the key locator programming model for V6 and later. For the JAX-WS model, the pluggable token framework reuses the same framework from the WSS API. The same implementation for creating and validating a security token can be used in both the WS-Security run time and the WSS API application. This simplifies the SPI model and makes it easier to add new or custom security token types. The redesigned SPI consists of the following interfaces:

When using JAX-WS, the following interfaces are no longer required:

We can learn more about custom security tokens by reading these articles on the IBM developerWorks Web site:

 

Signing or encrypting any XML element

An XPath expression is used 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. In JAX-RPC Web services, the XPath expression is specified in the application deployment descriptor. In JAX-WS Web services, the XPath expression is specified in the WS-Security policy of the policy set.

The JAX-WS model uses policy sets to indicate the message parts where security should be applied. For example, the <Body> assertion is used to indicate that the body of the SOAP message is signed or encrypted. Another example is the <Header> assertion, where the QName of the SOAP header to be signed or encrypted is specified.

 

Signing or encrypting SOAP headers

The OASIS Web Service Security (WS-Security) V1.1 support provides for a standard way of encrypting and signing SOAP headers. To sign or encrypt SOAP messages, specify the QName to select header elements in the SOAP header of the SOAP message.

Configure policy sets for signing or encrypting either by using the admin console or by using WS-Security APIs (WSS APIs). For more details, see the topic Securing message parts using the admin console. For signing, specify the following:

Name

This optional attribute indicates the local name of the SOAP header to be integrity protected. If this attribute is not specified, all SOAP headers whose namespace matches the Namespace attribute are to be protected.

Namespace

This required attribute indicates the namespace of the SOAP headers to be integrity protected.

For encrypting, specify the following:

Name

This optional attribute indicates the local name of the SOAP header to be confidentiality protected. If this attribute is not specified, all SOAP headers whose namespace matches the Namespace attribute are to be protected.

Namespace

This required attribute indicates the namespace of the SOAP header(s) to be confidentiality protected.
This results in an <EncryptedHeader> element that contains the <EncryptedData> element.

For WS-Security V1.0 behavior, specify the com.ibm.wsspi.wssecurity.encryptedHeader.generate.WSS1.0 property with a value of true in EncryptionInfo in the bindings. Specifying this property results in an <EncryptedData> element.

For WS-Security V1.1 behavior that is equivalent to WAS versions prior to version 7.0, specify the com.ibm.wsspi.wssecurity.encryptedHeader.generate.WSS1.1.pre.V7 property with a value of true on the <encryptionInfo> element in the binding. When this property is specified, the <EncryptedHeader> element includes a wsu:Id parameter and the <EncryptedData> element omits the Id parameter. This property should only be used if compliance with Basic Security Profile 1.1 is not required and it is necessary to send <EncryptedHeader> elements to a client or server that uses the WAS V5.1 Feature Pack for Web Services.

 

Supporting LTPA

LTPA is supported as a binary security token in WS-Security. Web services security supports both LTPA (version 1) and LTPA version 2 tokens. The LTPA version 2 token, which is more secure than version 1, is supported in WAS version 7.0.

 

Extending the support for timestamps

We 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 WAS. 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

We 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 WAS. 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 WAS Vs 6 and later that enables you to replicate nonce data between servers in a cluster. For example, we might have appserver A and application server B in cluster C. If appserver A accepts a nonce with a value of X, then appserver B creates a SoapSecurityException if it receives the nonce with the same value within a specified period of time.

The distributed nonce caching feature uses the WAS 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 appserver within the cluster is updated. The delay might be due to network traffic, network workload, machine workload, and so on. For adequate security protection, enable appropriate security for the DRS cache. See the topic Multi-broker replication domains for more information.

 

Caching the X.509 certificate

WAS caches 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. We can disable X.509 certificate caching by using the On the cell level:

On the server level:

 

Providing support for a certificate revocation list

The certificate revocation list (CRL) in WAS is used to enhance certificate path validation. We can specify a CRL in the collection certificate store for validation. We can also encode a CRL in an X.509 token using PKCS#7 encoding. However, WAS V 6 and later do not support X509PKIPathv1 CRL encoding in a X.509 token.

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
Multi-broker replication domains
Certificate revocation list
Nonce, a randomly generated token
Assembly tools
Distributed nonce cache
Encrypted SOAP headers
Web Services Secure Conversation
Trust service
Web services policy sets
Web services policies
Trusted ID evaluator
What is new for securing Web services

 

Related tasks

Secure message parts
Manage policies in a policy set
Secure JAX-RPC Web services using message level security
Manage policy sets
Secure requests to the trust service using system policy sets