SAML Sender Vouches with Certificates (Using the HTTP Binding Component)

Using the HTTP Binding Component

SAML Sender Vouches with Certificates

This mechanism uses mutual certificates to provide integrity and confidentiality for messages, and uses a Sender Vouches SAML token to provide authorization. The Sender Vouches method establishes correspondence between a SOAP message and the SAML assertions added to the SOAP message. Confirmation evidence, used to establish correspondence between the subject of the SAML subject statements (in SAML assertions) and SOAP message content, is provided by the attesting entity.

The message payload needs to be signed and encrypted. The requestor is vouching for the credentials (present in the SAML assertion) of the entity on behalf of which the requestor is acting. The initiator token, which is an X.509 token, is used for signature. The recipient token, which is also an X.509 token, is used for encryption. For the server, this is reversed, the recipient token is the signature token and the initiator token is the encryption token. A SAML token is used for authorization.

For an example of configuring WS Security for SAML Sender Vouches with Certificates see Using the SAML Sender Vouches with 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: 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.
Truststore: Configure the Truststore that 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.
SAML Callback Handler: Specify a SAML Callback Handler. To use a SAML Callback Handler, you need to create one, as there is no default.

Table 27 SAML Sender Vouches with Certificates Configuration Properties


Property	Description	Value
SAML Version	Specifies which version of the SAML token should be used. The SAML Version is something the CallbackHandler has to verify, not the security runtime. SAML tokens are defined in WSS: SAML Token Profile documents, available from `http://www.oasis-open.org/specs/index.php`.	1.1 (Profile 1.0)
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 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.