About Security Mechanism Options for Web Services

See Also 

In the Web Service Attributes Editor, within the WSIT tab's Service Port Binding section, you can define the following security mechanism options:

• Username Authentication with Symmetric Keys. 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 encrypt and decrypt a message. Symmetric keys are usually faster than public key cryptography.

  For this mechanism, the client does not possess any certificates, but shares a secret key with the server certificate. The shared, symmetric key is generated at runtime and encrypted using the service’s certificate. The client must specify the alias in the truststore by specifying the server’s certificate.

• Mutual Certificates Security. The Mutual Certificates Security mechanism adds security via authentication and message protection that ensures integrity and confidentiality. When using mutual certificates, a keystore and truststore file must be configured for the server.

  You do not need to do any additional configuration to configure the service for secure communication using Mutual Certificates Security. Optionally, you can configure additional options.

• Transport Security (SSL). The Transport Security mechanism protects your application during transport using SSL for authentication and confidentiality. Transport-layer security is provided by the transport mechanisms used to transmit information over the wire between clients and providers, thus transport-layer security relies on secure HTTP transport (HTTPS) using Secure Sockets Layer (SSL). Transport security is a point-to-point security mechanism that can be used for authentication, message integrity, and confidentiality. When running over an SSL-protected session, the server and client can authenticate one another and negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. Security is "live" from the time it leaves the consumer until it arrives at the provider, or vice versa, even across intermediaries. The problem is that it is not protected once it gets to its destination. For protection of data after it reaches its destination, use one of the security mechanisms that uses SSL and also secures data at the message level.

  Digital certificates are necessary when running secure HTTP transport (HTTPS) using Secure Sockets Layer (SSL). The HTTPS service of most web servers will not run unless a digital certificate has been installed. Digital certificates have already been created for GlassFish, however, the WSIT technology requires a newer version of certificates than is available with GlassFish.

• 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.

  To use this mechanism, make sure that SSL is configured on the server. When using SSL, a keystore and a truststore file must be configured for the server.

  You do not need to do any additional configuration to configure the service for secure communication using Message Authentication over SSL. Optionally, you can configure additional options.

• SAML Authorization over SSL. The SAML Authorization over SSL mechanism attaches an authorization token with the message and uses SSL for confidentiality protection. In this mechansim, the SAML token is expected to carry some authorization information about an end user. The sender of the token is actually vouching for the credentials in the SAML token.

  To use this mechanism, make sure that SSL is configured on the server. When using SSL, a keystore and a truststore file must be configured for the server.

  You do not need to do any additional configuration to configure the service for secure communication using SAML Authorization over SSL. If you’d like, yo can configure additional options.

• Endorsing Certificate. This mechanism uses secure messages using a random symmetric key for integrity and confidentiality protection. For this mechanism, the client knows the service’s certificate, and you must have a client certificate endorsed by a SAML token issued by a designated Secure Token Service (STS) to augment the claims provided by the token associated with the message signature.

  You do not need to do any additional configuration to configure the service for secure communication using this mechanism. If you like, however, you can configure additional options.

• SAML Sender Vouches with Certificates. This mechanism protects messages with mutual certificates for integrity and confidentiality and with a Sender Vouches SAML token for authorization. The Sender Vouches method establishes the correspondence between a SOAP message and the SAML assertions added to the SOAP message. The attesting entity provides the confirmation evidence that will be used to establish the correspondence between the subject of the SAML subject statements (in SAML assertions) and SOAP message content.

  The attesting entity, presumed to be different from the subject, vouches for the verification of the subject. The receiver has an existing trust relationship with the attesting entity. The attesting entity protects the assertions (containing the subject statements) in combination with the message content against modification by another party. For more information about the Sender Vouches method, read the SAML Token Profile document at http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf.

• SAML Holder of Key. This mechanism protects messages with a signed SAML assertion (issued by a trusted authority) carrying client public key and authorization information with integrity and confidentiality protection using mutual certificates. The Holder-of- Key (HOK) method establishes the correspondence between a SOAP message and the SAML assertions added to the SOAP message. The attesting entity includes a signature that can be verified with the key information in the confirmation method of the subject statements of the SAML assertion referenced for key info for the signature. For more information about the Holder of Key method, read the SAML Token Profile document at http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf.
• STS Issued Token. This security mechanism protects messages using a token issued by a trusted Secure Token Service (STS) for message integrity and confidentiality protection.

  An STS is a service that implements the protocol defined in the WS-Trust specification. This protocol defines message formats and message exchange patterns for issuing, renewing, canceling, and validating security tokens.

• STS Issued Token with Service Certificate. This security mechanism is similar to the one discussed in STS Issued Token, with the enhancement that in addition to the service requiring the client to authenticate using a SAML token issued by a designated STS, confidentiality protection is achieved using a service certificate. A service certificate is used by a client to authenticate the service and provide message protection. For GlassFish, a default certificate of s1as is installed.
• STS Issued Endorsing Token.
This security mechanism is similar to the one discussed in STS Issued Token, with the enhancement that the client authenticates using a SAML token that is both issued and endorsed by a designated STS. An endorsing token is used to sign the message signature. In this mechanism, 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.