Web services security enhancements

WebSphere Application Server Versions 6 and later include a number of enhancements for securing Web services. Policy sets, or assertions about services are defined, can be used to simplify your security configuration for 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.

New or updated for this feature pack In IBM WebSphere Application Server Version 6.1 Feature Pack for Web Services, WebSphere Application Servers also uses another Web Services Security runtime, which is new and based on the Java API for XML Web Services (JAX-WS) programming model and the updated SAAJ programming model. Instead of deployment descriptor and bindings, a policy set is used for configuration.

New or updated for this feature pack This JAX-WS programming model is substantially different from the IBM Web services runtime implementation and the application programming model JAX-RPC (JSR-109) that is used with previous WebSphere Application Server versions. New enhancements include the flexibility to support different message exchange patterns, asynchronous method invocation, an AXIOM data model, and so forth.

Using policy sets New or updated for this feature pack

In IBM WebSphere Application Server Version 6.1 Feature Pack for Web Services, policy sets can be used to simplify your Web service Quality of Service configuration.

Note: Policy sets can only be used with JAX-WS applications. Policy sets cannot be used for JAX-RPC applications.
Policy sets combine configuration settings, including those for transport and message level configuration, such as Web Services Addressing (WS-Addressing), Web Services Reliable Messaging (WS-ReliableMessaging), Web Services Secure Conversation (WS-SecureConversation), and Web Services Security (WS-Security). Policy sets can be:
  • Created
  • Edited
  • Deleted
  • Attached to resources, such as applications and system
  • Detached from resources, such as applications and system
  • Exported

Managing trust policies New or updated for this feature pack

In IBM WebSphere Application Server Version 6.1 Feature Pack for Web Services, Web Services Security Trust (WS-Trust) provides the ability for an endpoint to issue a security context token for Web Services Secure Conversation (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 WebSphere Application Server trust service policies.

Securing session-based messages New or updated for this feature pack

In IBM WebSphere Application Server Version 6.1 Feature Pack for Web Services, 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 Web Services Security Reliable Messaging (WS-ReliableMessaging). The symmetric cryptographic algorithm should provide better performance and throughput when compared to asymmetric cryptographic algorithm

Updating message-level security New or updated for this feature pack

In IBM WebSphere Application Server Version 6.1 Feature Pack for Web Services, two Web Services Security (WS-Security) Version 1.1 functions update the message-level security.
  • Signature confirmation
  • Encrypted headers

Signature confirmation enhances XML digital signature security and provides message-level security that is more secure. 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 one of the extensions to the Organization for the Advancement of Structured Information Standards (OASIS) 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.

Using the pluggable token framework New or updated for this feature pack

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 pluggable token framework has been redesigned to allow the same implementation that is used for creating and validating a security token to also be used in the Web Service Security runtime. The redesigned framework simplifies the programming model and makes it easier to add new or custom security token types.

The following interfaces are used:
  • The JAAS CallbackHandler and the JAAS Login Module are responsible for creating the security token on the generator side and validating (authenticating) the security token in the consumer side.
  • The security token interface (com.ibm.websphere.wssecurity.wssapi.token.SecurityToken) represents the security token, and it is used to get the identity, XML format and cryptographic keys information.

The following scenario briefly describes how to create a Username token and how to validate the Username token.

Generic TokenGenerator
On the generator side, the Username token is created by the JAAS LoginModule
CallbackHandler
The JAAS CallbackHandler is used to pass the authentication data.
JAAS LoginModule
The JAAS LoginModule creates the Username SecurityToken object and passes it to the Web Services Security runtime.
Generic TokenConsumer
On the consumer side, the Username Token XML format is passed to the JAAS LoginModule for validation or authentication.
CallbackHandler
The JAAS CallbackHandler is used to pass authentication data from the Web Services Security runtime to the JAAS LoginModule.
JAAS LoginModule
The JAAS login configuration is responsible for validating the token or authentication. After the token is authenticated, a Username SecurityToken object is created and it passed to the Web Service Security runtime.

Signing or encrypting SOAP headers New or updated for this feature pack

The OASIS Web Service Security (WS-Security) Version 1.1 support provides for a standard way of encrypting and signing SOAP headers. In the IBM WebSphere Application Server Version 6.1 Feature Pack for Web Services, to sign or encrypt SOAP messages, specify the QName to select header elements in the SOAP header of the SOAP message.

You can configure policy sets for signing or encrypting either by using the administrative console or by using Web Services Security APIs (WSS APIs).

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 Web Services Security Version 1.0 behavior, specify the com.ibm.ws.wssecurity.encryptedHeader.generate.WSS1.0 property with a value of true in EncryptionInfo in the bindings. Specifying this property results in an EncryptedData element.

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.

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
Distributed nonce cache
Encrypted SOAP headers
Web Services Secure Conversation
Trust service
Web services policy sets
Web services policies
What is new for securing Web services
Related tasks
Managing policies in a policy set using the administrative console
Managing policy sets using the administrative console
Securing requests to the trust service using system policy sets
Concept topic Concept topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 1:23:07 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-dist&topic=cwbs_wssv6enhance
File name: cwbs_wssv6enhance.html