The Mutual Certificates Security mechanism uses security through authentication and message protection to ensure integrity and confidentiality. This mechanism requires a keystore and truststore file for both the client and server sides of the application.
For an example of configuring WS Security for Mutual Certificates Security see Using the WSIT Mutual Certificates Security Mechanism with the HTTP BC
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.
Truststore (no alias): Configure the Truststore to specify the alias that contains the certificate and trusted roots of the client. For the GlassFish Truststores, the file is cacerts. jks and the alias is xws-security-client, assuming that you have updated the GlassFish default certificate stores.
Client-Side Requirements
The following client-side options need to be configured for this security mechanisms:
Keystore: Cconfigure 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.
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.
Property |
Description |
Value |
---|---|---|
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 |
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 Session) 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. 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. See Require Derived Keys above for more information. |
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. |