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.

Summary of Service-Side Configuration Requirements

Table 6-1 summarizes the options that need to be configured for each of the security mechanisms. Each of the columns is briefly discussed after the table.

Table 6-1 Summary of Service-Side Configuration Requirements  
Mechanism
Keystore
Truststore
STS
SSL
User in
GlassFish
Username Auth. w/Symmetric Keys
YES
 
 
 
YES
Mutual Certs.
YES
YES
(no alias)
 
 
 
Transport Sec.
 
 
 
YES
YES
Message Auth. over SSL - Username Token
 
 
 
YES
YES
Message Auth. over SSL - X.509 Token
 
YES
(no alias)
 
YES
 
SAML Auth. over SSL
YES
YES
(no alias)
 
YES
 
Endorsing Cert.
YES
YES
 
 
 
SAML Sender Vouches with Cert.
YES
YES
(no alias)
 
 
 
SAML Holder of Key
YES
YES
(no alias)
 
 
 
STS Issued Token
YES
YES
YES
 
 
STS Issued Token with Service Cert.
YES
YES
YES
 
 
STS Issued Endorsing Token
YES
YES
YES
 
 

Summary of Client-Side Configuration Requirements

Table 6-2 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.

Table 6-2 Summary of Client-Side Configuration Requirements  
Mechanism
Key
store
Trust
store
Default
User
SAML Callback Handler
STS
SSL
User in
GF
Username Auth. w/Symmetric Keys
 
YES
YES
 
 
 
YES
Mutual Certs.
YES
YES
 
 
 
 
 
Transport Sec.
 
 
 
 
 
YES
YES
Message Auth. over SSL - Username Token
 
 
YES
 
 
YES
YES
Message Auth. over SSL - X.509 Token
YES
 
 
 
 
YES
 
SAML Auth. over SSL
YES
YES
 
YES
 
YES
 
Endorsing Cert.
YES
YES
 
 
 
 
 
SAML Sender Vouches with Cert.
YES
YES
 
YES
 
 
 
SAML Holder of Key
YES
YES
 
YES
 
 
 
STS Issued Token
YES
YES
 
 
Y
 
 
STS Issued Token with Service Cert.
YES
YES
 
 
Y
 
 
STS Issued Endorsing Token
YES
YES
 
 
Y
 
 

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 leave all of these options blank and 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.

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 WSIT tab to display the WSIT options.
  6. Expand the Username Authentication section to specify the user name and password information as required by the service. The dialog displays as follows:

Figure 6-3 WSIT Configuration - Client - Username Authentication

  1. The following options are available:

    2. NOTE: 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.

  2. Authentication Credentials--Select Static or Dynamic.
  3. Default Username, Default Password--Enter the name of an authorized user and the password for this user. This option is best used only in the development environment. When the Default Username and Default Password are specified, the username and password are stored in the wsit-client.xml file in clear text, which presents a security risk. Do not use this option for production.
  4. SAML Callback Handler--To use a SAML Callback Handler, you need to create one, as there is no default. References to example SAML Callback Handlers are provided in Example SAML Callback Handlers. An example that uses a SAML Callback Handler can be found in Example: SAML Authorization over SSL (SA).

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.

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;
}