test

The WSIT Tutorial

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:

Summary of Service-Side Configuration Requirements

Table 7–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 7–1 Summary of Service-Side Configuration Requirements

Mechanism 

Keystore 

Truststore 

STS 

SSL 

User in GlassFish 

Username Authentication with Symmetric Keys 

X 

     

X 

Mutual Certificates 

X 

X (no alias) 

     

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 

X (no alias) 

 

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 

   

Summary of Client-Side Configuration Requirements

Table 7–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 7–2 Summary of Client-Side Configuration Requirements

Mechanism 

Keystore 

Truststore 

Default User 

SAML Callback Handler 

STS 

SSL 

User in GlassFish 

Username Authentication with Symmetric Keys 

 

X 

X 

     

X 

Mutual Certificates 

X 

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 

   

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.

ProcedureTo 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 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 appears as shown in Figure 7–3.

    Figure 7–3 WSIT Configuration - Client - Username Authentication

    Screen shot of WSIT configuration - client - username authentication

  7. The following options are available.

    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.

    • Authentication Credentials: Select Static or Dynamic.

    • Default Username, Default Password: Type 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.

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