+

Search Tips   |   Advanced Search

WS-Security support


IBM supports WS-Security, which is an extension of the Web services engine, to provide a quality of service. The WAS security infrastructure fully integrates WS-Security with the Java EE security specification.

There is an important distinction between V5.x and V6.0.x and later applications. The information in this article supports V5.x applications only that are used with WAS Version 6.0.x and later. The information does not apply to Version 6.0.x and later applications.

WAS, Vs 4.x, 5, and 5.0.1 support digital signature for Apache SOAP V2.x. Beginning with WAS, V5.0.2, IBM supports WS-Security. The IBM implementation is based on the Web services security specification, WS-Security, originally proposed by IBM, Microsoft, and VeriSign in April 2002. Early versions of the proposed draft specification can be found in WS-Security V1.0 05 April 2002 and WS-Security Addendum 18 August 2002. The WAS implementation is based on the Organization for the Advancement of Structured Information Standards (OASIS) working Draft 13 specification. (See the OASIS Web Services Security TC Web site for the latest working specification.) However, not all the features in the OASIS working Draft 13 specification are implemented.

WS-Security is not supported in a pure Java client or a nonmanaged client. When a user ID and password are embedded in a request message, authentication is performed with the user ID and password. If authentication is successful, a user identity is established and further resource access is authorized based on that identity. After the user ID and password are authenticated by the WS-Security run time, a Java EE container performs authorization. WAS provides an implementation of the key features of Web services security based on the following specifications:

The following table provides a summary of Web services security elements supported by WAS:


Table 1. Supported WS-Security elements

Element Notes
UsernameToken Both the user name and password for the BasicAuth authentication method and the user name for the identity assertion authentication method are supported. WAS supports nonce, a randomly generated value.
BinarySecurityToken X.509 certificates and LTPA can be embedded, but there is no implementation to embed Kerberos tickets. However, the binary token generation and validation are pluggable and are based on the Java Authentication and Authorization Service (JAAS) Application Programming Interfaces (APIs). We can extend this implementation to generate and validate other types of binary security tokens.
Signature The X.509 certificate is embedded as a binary security token and can be referenced by the SecurityTokenReference. WAS does not support shared, key-based signature.
Encryption Both the EncryptedKey and ReferenceList XML tags are supported. KeyIdentifier specifies public keys and KeyName identifies the secret keys. WAS has the capability to map an authenticated identity to a key for encryption or use the signer certificate to encrypt the response message.
Time stamp WAS supports the Created and Expires attributes. The freshness of the message, which indicates whether the message complies with predefined time constraints, is checked only if the Expires attribute is present in the message. WAS does not support the Received attribute, which is defined in the addendum. Instead, WAS uses the TimestampTraceReceived attribute, which is defined in the OASIS specification.
XML-based token We can insert and validate an arbitrary format of XML tokens into a message. This format mechanism is based on the JAAS APIs.

Signing and encrypting attachments is not supported by WAS. However, WAS signs and encrypts the following elements for the request message.


Table 2. Elements that are signed and encrypted for the request message

Method Element
XML digital signature

  • Body

  • Securitytoken

  • Timestamp

XML encryption

  • Bodycontent

  • Usernametoken

AuthMethod

  • BasicAuth

  • IDAssertion (from WAS to another WAS

  • Signature
  • LTPA on the server side

  • Other customer tokens

WAS signs and encrypts the following elements for the response message:


Table 3. Elements that are signed and encrypted for the response message

Method Element
XML digital signature

  • Body

  • Timestamp

XML encryption

  • Bodycontent

The namespaces that are used for sending a message were published by OASIS in draft 13 (http://schemas.xmlsoap.org/ws/2003/06/secext). However, the WS-Security run time in WAS can accept any of the following namespaces:

April 2002 spec

http://schemas.xmlsoap.org/ws/2002/04/secext

August 2002 addendum

http://schemas.xmlsoap.org/ws/2002/07/secext

http://schemas.xmlsoap.org/ws/2002/07/utility

OASIS draft published on draft 13 May 2003

http://schemas.xmlsoap.org/ws/2003/06/secext

http://schemas.xmlsoap.org/ws/2003/06/utility

WAS only uses the previously mentioned two namespaces for sending out requests and responses. However, WAS can process all other mentioned namespaces for incoming requests and responses.

WAS provides the following capabilities for WS-Security:

Refer to the WS-Security elements table for a description of capabilities that are not supported.


 

Related concepts


WS-Security specification—a chronology
WS-Security and Java EE security relationship
WS-Security model in WAS

 

Related tasks


Secure Web services for V5.x applications based on WS-Security

 

Related information


OASIS WS-Security TC
Specification: WS-Security
WS-Security Addendum
Specification: WS-Security Version 1.0 05 April 2002
WS-Security: SOAP Message Security Working 13 May 2003
WS-Security: Username Token Profile Draft
WS-Security April 2002
WS-Security August 2002 Addendum Example 1
WS-Security August 2002 Addendum Example 2
WS-Security OASIS Draft 13 Example 1
WS-Security OASIS Draft 13 Example 2