STS Issued Endorsing Token (Using the HTTP Binding Component)

Using the HTTP Binding Component

STS Issued Endorsing Token

Similar to STS Issued Token, except that the client authenticates using a SAML token that is issued by a designated STS. An endorsing token is used to sign the message signature.

Message integrity and confidentiality are protected using ephemeral keys encrypted for the service. Ephemeral keys use an algorithm where the exchange key value is purged from the cryptographic service provider (CSP) when the key handle is destroyed. The service requires messages to be endorsed by a SAML token issued by a designated STS.

For this mechanism, the service requires that secure communications be endorsed by a trusted STS. The service does not trust the client directly, but instead trusts tokens issued by a designated STS. In other words, the STS is taking on the role of a second service with which the client has to securely authenticate.

To use this mechanism for the web service, select this option as your security mechanism. You must have a Security Token Service that can be referenced by the service. The security configuration for the client-side of this application is dependent upon the security mechanism selected for the STS, and not on the security mechanism selected for the application. The client Truststore must contain the certificate of the STS, which has the alias of wssip if you are using the updated GlassFish certificates.

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: 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.
STS: You must have a Security Token Service that can be referenced by the service. The STS is secured using a separate (non-STS) security mechanism.

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.
STS: You must have a Security Token Service that can be referenced by the service. The STS is secured using a separate (non-STS) security mechanism. The security configuration for the client-side of this application is dependent upon the security mechanism selected for the STS, and not on the security mechanism selected for the application.

Table 31 STS Issued Endorsing Token Configuration Properties


Property	Description	Value
Issuer Address	Specifies the address of the issuer (STS) that will accept the security token presented in the message. The element type is an endpoint reference. An STS contains a set of interfaces used to issue, exchange, and validate security tokens. For example, for JAX-WS services, the Issuer Address is: `http://localhost:8080/jaxws-sts/sts`	http://localhost:8080/jaxws-sts/sts
Issuer Metadata Address	Specifies the address from which to retrieve the issuer metadata. This should just be the URLs. For example, for JAX-WS services, the Issuer Metadata Address is as follows: `http://localhost:8080/jaxws-sts/sts`	http://localhost:8080/jaxws-sts/sts
Token Type	Specifies the type of SAML token required by the service provider. For example: `urn:oasis:names:tc:SAML1.0:assertion`. The options are 1.0, 1.1, or 2.0.	1.1
Key Type	Specifies the type of key preferred by the service provider. The choices are public key or symmetric key: Symmetric Key cryptography relies on a shared secret and is usually faster than Public Key cryptography Public Key cryptography relies on a key that is made public to all and is primarily used for encryption but can be used for verifying signatures. Applies to Issued Token mechanisms only.	Symmetric Key
Key Size	Specifies the size of the symmetric key requested in number of bits. This information is provided as an indication of the desired strength of the security. Valid choices include 128, 192, and 256. The security token is not obligated to use the requested key size, nor is the STS obligated to issue a token with the same key size. That said, the recipient should try to use a key at least as strong as the specified value if possible. Applies to Issued Token mechanisms only.	128
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 for X509 Token	Specifies that a derived key is required for X509 Token. See Require Derived Key above for more information. 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 X509 Token.	Select the checkbox to enable.
Require Derived Keys for Issued Token	Specifies that a derived key is required for Issued Token. See Require Derived Keys for X509 Token above for more information.	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 for X509 Token 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.