Web Services Security enhancements
WebSphere® Application Server includes a number of enhancements for securing web services. For example, policy sets are supported in WebSphere Application Server Version 6.1 Feature Pack for Web Services, and later, to simplify security configuration for web services.
Building your applications
The Web Services Security runtime implementation used by WebSphere Application Server Version 8 is based on the Java™ API for XML Web Services (JAX-WS) programming model. The JAX-WS runtime environment 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. You can use the WebSphere Application Server administrative console to edit the application binding files associated with the policy sets. The JAX-WS runtime environment is supported for the WebSphere Application Server V6.1 Feature Pack for Web Services, and later.
The JAX-RPC programming model, which uses deployment descriptors and bindings, is still supported. Read the topic Securing JAX-RPC Web services using message level security for more information.
Using policy sets
Use policy sets to simplify your web service Quality of Service configuration.
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), and Web Services Security (WS-Security), which includes Secure Conversation (WS-SecureConversation).
Managing trust policies
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
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).
Updating message-level security
- Signature confirmation
- Encrypted headers
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 services 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.
Using identity assertion
- A username token without a password
- An X.509 Token for a X.509 certificate
For more information about identity assertion, read the topic Trusted ID evaluator.
Signing or encrypting data with a custom token
For the JAX-RPC programming 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 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.
- The JAAS CallbackHandler and JAAS Login Module create security tokens on the generator side and validate, or authenticate, security tokens on the consumer side.
- The Security Token interface, com.ibm.websphere.wssecurity.wssapi.token.SecurityToken, represents the security token that has methods to get the identity, XML format and cryptographic keys.
- Token Generator (com.ibm.wsspi.wssecurity.token.TokenGeneratorComponent)
- Token Consumer (com.ibm.wsspi.wssecurity.token.TokenConsumerComponent)
- Key Locator (com.ibm.wsspi.wssecurity.keyinfo.KeyLocator)
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 programming 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 Services Security (WS-Security) Version 1.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.
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 more details, see the topic Securing message parts using the administrative console.
- 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.
- 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.
For Web Services Security Version 1.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 Web Services Security Version 1.1 behavior that is equivalent to WebSphere Application Server 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 WebSphere Application Server Version 5.1 Feature Pack for Web Services.
Supporting LTPA
Lightweight Third Party Authentication (LTPA) is supported as a binary security token in Web Services 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 WebSphere Application Server version 7.0 and later.
Extending the support for timestamps
You can insert a timestamp during the signing process in elements other than 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 elements other than 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 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.
Caching the X.509 certificate
WebSphere Application Server 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. You can disable X.509 certificate caching by using the following steps:
- 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.
- 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.