Web services security support: WAS v5.1

Web services security support

WAS, Versions 4.x, 5, and 5.0.1 support digital signature for Apache Simple Object Access Protocol (SOAP) Version 2.x. Beginning with WAS, V5.2, IBM supports Web services security, which is an extension of the IBM Web services engine to provide a quality of service. The IBM implementation is based on the Web services security specification, "Web Services Security (WS-Security)", originally proposed by IBM, Microsoft, and VeriSign in April 2002. Early versions of the proposed draft specification can be found in Web Services Security (WS-Security) Version 1.0 05 April 2002 and Web Services 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.
WAS security infrastructure fully integrates Web services security with Java 2 Platform, Enterprise Edition (J2EE) security. 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 Web services security run time, a J2EE container performs authorization.
WAS provides an implementation of the key features of Web services security based on the following specifications...

Specification: Web Services Security (WS-Security) Version 1.0 05 April 2002
Web Services Security Addendum 18 August 2002
Web Services Security: SOAP Message Security Working 13 May 2003
Web Services Security: Username Token Profile Draft

The following table provides a summary of Web services security elements supported by WAS:
Web services 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, Version 5.1 supports nonce, a randomly generated value.
BinarySecurityToken X.509 certificates and Lightweight Third Party Authentication (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 JAAS Application Programming Interfaces (APIs). You 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.
Timestamp 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 TimestampTrace Received attribute, which is defined in the OASIS specification.
XML based token You 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 WebSphere Application Server. However, WAS signs and encrypts the following elements for the request message.

Method Element
XML digital signature

Body
Securitytoken
Timestamp

XML encryption

Bodycontent
Usernametoken

AuthMethod

BasicAuth
IDAssertion (From WAS to another WebSphere Application Server
Signature
Lightweight Third Party Authentication (LTPA) on the server side
Other customer tokens

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

Method Element
XML digital signature

Body
Timestamp

XML encryption

Bodycontent

The namespaces used for sending a message were published by OASIS in draft 13 (http://schemas.xmlsoap.org/ws/2003/06/secext ).

April 2002 specification 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
Note that WAS only uses the previously mentioned two name spaces for sending out requests and responses. However, the product can process all other mentioned name spaces for incoming requests and responses.

WAS provides the following capabilities for Web services security...

Integrity of the message
Authenticity of the message
Confidentiality of the message
Privacy of the message
Transport level security: provided by SSL
Security token propagation (pluggable)
Identity assertion

See the previous table titled, "Web services security elements," for a description of capabilities that are not supported.

See Also
Web services security specification- a chronology
Web services security and Java 2 Platform, Enterprise Edition security relationship
Web services security model in WAS
Securing Web services based on WS-Security
OASIS Web Services Security TC
Specification: Web Services Security (WS-Security)
Web Services Security Addendum
Specification: Web Services Security (WS-Security) Version 1.0 05 April 2002
Web Services Security Addendum 18 August 2002
Web Services Security: SOAP Message Security Working 13 May 2003
Web Services 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

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, Version 5.1 supports nonce, a randomly generated value.
BinarySecurityToken	X.509 certificates and Lightweight Third Party Authentication (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 JAAS Application Programming Interfaces (APIs). You 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.
Timestamp	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 TimestampTrace Received attribute, which is defined in the OASIS specification.
XML based token	You can insert and validate an arbitrary format of XML tokens into a message. This format mechanism is based on the JAAS APIs.

April 2002 specification	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 Note that WAS only uses the previously mentioned two name spaces for sending out requests and responses. However, the product can process all other mentioned name spaces for incoming requests and responses.