Back to Metro Guide

12.2. Summary of Configuration Requirements

The following sections summarize the options that need to be configured for each of the security mechanisms on both the service and client side. The configuration requirements for the client are dependent upon which security mechanism is specified on the server side.

This section covers the following topics:

12.2.1. Summary of Service-Side Configuration Requirements

Summary of Service-Side Configuration Requirements summarizes the options that need to be configured for each security mechanism. Each of the columns is briefly discussed after the table.

Summary of Service-Side Configuration Requirements

Mechanism

Keystore

Truststore

STS

SSL

User in GlassFish

Kerberos

Username Authentication with Symmetric Key

X

X

Username Authentication with Password Derived Keys

X

Mutual Certificates

X

X (no alias)

Symmetric Binding with Kerberos Tokens

X

Transport Security

X

X

Message Authentication over SSL - Username Token

X

X

Message Authentication over SSL - X.509 Token

X (no alias)

X

SAML Authorization over SSL

X

Endorsing Certificate

X

X

SAML Sender Vouches with Certificate

X

X (no alias)

SAML Holder of Key

X

X (no alias)

STS Issued Token

X

X

X

STS Issued Token with Service Cert.

X

X

X

STS Issued Endorsing Token

X

X

X

12.2.2. Summary of Client-Side Configuration Requirements

Summary of Client-Side Configuration Requirements summarizes the options that need to be configured for each of the security mechanisms on the client-side. Each of the columns is briefly discussed after the table.

Summary of Client-Side Configuration Requirements

Mechanism

Keystore

Truststore

Default User

SAML Callback Handler

STS

SSL

User in GlassFish

Kerberos

Username Authentication with Symmetric Key

X

X

X

Username Authentication with Password Derived Keys

X

X

Mutual Certificates

X

X

Symmetric Binding with Kerberos Tokens

X

Transport Security

X

X

Message Authentication over SSL - Username Token

X

X

X

Message Authentication over SSL - X.509 Token

X

X

SAML Authorization over SSL

X

X

X

X

Endorsing Certificate

X

X

SAML Sender Vouches with Certificate

X

X

X

SAML Holder of Key

X

X

X

STS Issued Token

X

X

X

STS Issued Token with Service Certificate

X

X

X

STS Issued Endorsing Token

X

X

X

12.2.2.1. Configuring Username Authentication on the Client

On the client side, a user name and password must be configured for some of the security mechanisms. For this purpose, you can use the default Username and Password Callback Handlers (when deploying to GlassFish), specify a SAML Callback Handler, specify a default user name and password for development purposes, create and specify your own Callback Handlers if the container you are using does not provide defaults, or specify the username and password dynamically at runtime. When using any of these options, you must create an authorized user on GlassFish using the Admin Console, as described in Adding Users to GlassFish.

To Configure Username Authentication on the Client

Once you've created an authorized user and determined how your application needs to specify the user, configure the Username Authentication options as follows.

  1. In the Projects window, expand the node for the web service client.
  2. Expand the Web Service References node.
  3. Right-click the node for the web service reference for which you want to configure security options.
  4. Select Edit Web Service Attributes.
  5. Select the Quality of Service tab to display the WSIT Security options.
  6. Expand the Security section to specify the user name and password information as required by the service. The dialog appears as shown in Quality of Service - Client - Security.
    Quality of Service - Client - Security
    Screen shot of Quality of Service configuration - client - security
  7. The following options are available.

    Currently the GlassFish CallbackHandler cannot handle the following: SAML Callbacks and Require ThumbPrint Reference assertions under an X.509 Token. This may be addressed in a future milestone.

12.2.2.2. Example SAML Callback Handlers

Creating a SAML Callback Handler is beyond the scope of this document. However, the following web pages may be helpful for this purpose:

When writing SAML Callback Handlers for different security mechanisms, set the subject confirmation method to SV (Sender Vouches) or HOK (Holder of Key) and the appropriate SAML Assertion version depending on the SAML version and SAML Token Profile selected when setting the security mechanism for the service. When the subject confirmation method is HOK, a keystore and truststore file must be configured in the SAMLCallbackHandler. When the method is SV, you can either comment out the keystore and truststore information, or leave it, as it will not be used.

For example, the following code snippet for one of the SAMLCallbackHandlers listed above demonstrates how to set the subject confirmation method and sets the SAMLAssertion version to 1.0, profile 1.0.

if (callbacks[i] instanceof SAMLCallback) {
    try {

        SAMLCallback samlCallback = (SAMLCallback)callbacks[i];

        /*
         Set confirmation Method to SV [SenderVouches] or HOK[Holder of Key]
        */
        samlCallback.setConfirmationMethod
            (samlCallback.SV_ASSERTION_TYPE);

        if (samlCallback.getConfirmationMethod().equals(
                samlCallback.SV_ASSERTION_TYPE)) {
            samlCallback.setAssertionElement
                (createSVSAMLAssertion());

            svAssertion_saml10 =
                 samlCallback.getAssertionElement();
            /*
            samlCallback.setAssertionElement
                (createSVSAMLAssertion20());
            svAssertion_saml20 =
                 samlCallback.getAssertionElement();
            */
        } else if (samlCallback.getConfirmationMethod().equals(
                samlCallback.HOK_ASSERTION_TYPE)) {
            samlCallback.setAssertionElement
                (createHOKSAMLAssertion());
            hokAssertion_saml10 =
                 samlCallback.getAssertionElement();
            /*
            samlCallback.setAssertionElement
                (createHOKSAMLAssertion20());
            hokAssertion_saml20 =
                 samlCallback.getAssertionElement();
            */
        }
    } catch (Exception e) {
        e.printStackTrace();
    }
} else {
    throw unsupportedCallback;
}