Message Authentication over SSL (Using the HTTP Binding Component)

Using the HTTP Binding Component

Message Authentication over SSL

The Message Authentication over SSL mechanism attaches a cryptographically secured identity or authentication token with the message and use SSL for confidentiality protection. Authentication is specified through a Username Supporting Token or an X.509 Supporting Token.

Server-Side Requirements

The following server-side options need to be configured for this security mechanisms:

SSL: Configure the system to point to the client and server Keystore and Truststore files.
User in GlassFish: Add a user to the file realm of GlassFish to use a mechanism that requires a user database for authentication.

Client-Side Requirements

The following client-side options need to be configured for this security mechanisms:

Keystore: Configure the keystore to point to the alias for the client certificate. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
SSL: Configure the system to point to the client and server Keystore and Truststore files.

Table 24 Message Authentication over SSL Configuration Properties


Property	Description	Value
Authentication Token	Specifies which supporting token will be used to sign and/or encrypt the specified message parts. Options include Username, X509, SAML, Issued, or None	Username
WSS Version	Specifies which version of the Web Services Security specification is followed. Options are 1.0 and 1.1. Enabling WSS 1.1 enables the Server to reuse an encrypted key already generated by the client. This saves the time otherwise required to create a Symmetric Key during the course of response, encrypt it with the client public key (which is also an expensive RSA operation), and transmit the encrypted key in the message (it occupies markup and requires Base64 operations). Enabling WSS 1.1 also enables encrypted headers.	1.1
Algorithm Suite	Specifies the algorithm suite required to perform cryptographic operations with symmetric or asymmetric key-based security tokens. See Algorithm Suite under Table 21 for more information.	Basic 128bit
Security Header Layout	Specifies the layout rule to apply when adding items to the security header. Options are Strict, Lax, Lax (Timestamp First), and Lax (Timestamp Last). See Security Header Layout under Table 21 for more information.	Strict
Establish Secure Session (Secure Conversation)	Secure Session enables establishes a shared security context between the consumer and provider when a multiple-message-exchange sequence is first initiated. Subsequent messages use (possibly derived) session keys that increase the overall security while reducing the security processing overhead for each message. For more information see Establish Secure Session under Table 21.	Select the checkbox to enable.
Require Derived Keys for Secure Session	Specifies that a derived key is required for Secure Session. A derived key is a cryptographic key created from a password or other user data. Derived keys allow applications to create session keys as needed, eliminating the need to store a particular key. The use of the same session key for repeated message exchanges is sometimes considered a risk. To reduce that risk, enable Require Derived Keys for Secure Session.	Select the checkbox to enable.
Require Signature Confirmation	Specifies that the responder process the signature in the request. Select this option to reduce the risk of attacks when the WSS Version is 1.1 .	Select the checkbox to enable.