Username Authentication with Symmetric Key (Using the HTTP Binding Component)

Using the HTTP Binding Component

Username Authentication with Symmetric Key

The Username Authentication with Symmetric Keys mechanism protects your application for integrity and confidentiality. Symmetric key cryptography relies on a single, shared, secret key that is used to both sign and encrypt a message, and is usually faster than public key cryptography.

Server-Side Requirements

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

Keystore: Configure the Keystore to specify the alias identifying the service certificate and private key. For the GlassFish Keystores, the file is keystore.jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.
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:

Truststore: Configure the Truststorethat contains the certificate and trusted roots of the server. For the GlassFish truststores, the file is cacerts. jks and the alias is xws-security-server, assuming that you have updated the GlassFish default certificate stores.When using an STS mechanism, the client specifies the Truststore and certificate alias for the STS, not the service. For the GlassFish stores, the file is cacerts.jks and the alias is wssip.
Default User: Configure either a default username and password, a UsernameCallbackHandler, or leave these options blank and specify a user at runtime.
User in GlassFish: Add a user to the file realm of GlassFish to use a mechanism that requires a user database for authentication.

Table 21 Username Authentication with Symmetric Key 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
Algorithm Suite	Specifies the algorithm suite required to perform cryptographic operations with symmetric or asymmetric key-based security tokens. An algorithm suite specifies actual algorithms and allowed key lengths. A mechanism alternative will define what algorithms are used and how they are used. The value of this attribute is typically referenced by a security binding and is used to specify the algorithms used for all cryptographic operations performed under the security binding. The default value is Basic 128 bit. Some of the algorithm suite settings require that Unlimited StrengthEncryption be configured in the Java Runtime Environment (JRE), particularly the algorithm suites that use 256 bit encryption. For instructions on downloading and configuring unlimited strength encryption, see: `http://java.sun.com/products/jce/javase.html` or `http://java.sun.com/javase/downloads/index_jdk5.jsp#docs`	Basic 128bit
Security Header Layout	Specifies the layout rule to apply when adding items to the security header. The options are: Strict: Items are added to the security header following the general principle of ?declare before use? Lax: Items are added to the security header in any order that conforms to WSS: SOAP Message Security. However, WSIT follows Strict even when Lax is selected. Lax (Timestamp First): The same as Lax, except that the first item in the security header must be a wsse:Timestamp. Lax (Timestamp Last):The same as for Lax, except that the last item in the security header must be a wsse:Timestamp.	Strict
Require Derived Keys	Specifies that a derived key is required. 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 example, when using Secure Conversation) for repeated message exchanges is sometimes considered a risk. To reduce that risk, enable Require Derived Keys.	Select the checkbox to enable.
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. When this option and Require Derived Keys are both enabled, a derived key will be used. If not, the original session key will be used. Note on Secure Session and Reliable Message Delivery: Reliable Messaging can be used independently of the security mechanisms; however, when used with a security mechanism, Reliable Messaging requires the use of Secure Session, which will be automatically configured for a security mechanism when Reliable Messaging is selected before the security mechanism is selected. If Secure Session is selected for a security mechanism and the Reliable Messaging option is not selected before the security mechanism is specified, Reliable Messaging will need to be manually selected in order for Secure Session to work.	Select the checkbox to enable.
Require Derived Keys for Secure Session	Specifies that a derived key is required for Secure Session. See Require Derived Key above for more information.	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.
Encrypt Signature	Specifies whether the primary signature and signature confirmation elements must be encrypted.	Select the checkbox to enable.
Encrypt before Signing	Specifies that the order of message protection is to encrypt the SOAP content, then sign the entire SOAP body. The encryption key and signing key must be derived from the same source key. If not selected, the default behavior is Sign Before Encrypt.	Check box Selected indicates disabled.