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
  • Keystore: If this column has an X, select Use Development Defaults, or click the Keystore button and 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've updated the GlassFish default certificate stores.

  • Truststore : If this column has an X, select Use Development Defaults, or click the Truststore button and configure the truststore to specify the alias that contains the certificate and trusted roots of the client. For the GlassFish keystores, the file is cacerts. jks and the alias is xws-security-client , assuming that you've updated the GlassFish default certificate stores.

  • STS : If this column has an X, you must have a Security Token Service that can be referenced by the service. An example of an STS can be found in the section To Create and Secure the STS (STS) . 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.

  • SSL : To use a mechanism that uses secure transport (SSL), you must configure the system to point to the client and server keystore and truststore files. Steps for doing this are described in Configuring SSL For Your Applications .

  • User in Glassfish : To use a mechanism that requires a user database for authentication, you can add a user to the file realm of GlassFish. Select Use Development Defaults, or follow the instructions for doing this at Adding Users to GlassFish .

  • Kerberos : This option is only valid for 'Symmetri Binding with Kerberos Tokens' Profile. Click the Kerbeos button to specify the login module to be used for this service. Login Modules can be specified in $GLASSFISH_HOME/domains/domain1/config/login.conf for Glassfish. An example showing use of Kerberos Tokens can be found at Example: Kerberos Token (Kerb).

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
  • Keystore: If this column has an X, select Use Development Defaults, or click Keystore to configure the keystore to point to the alias for the client certificate. For the GlassFish keystores, the keystore file is keystore.jks and the alias is xws-security-client, assuming that you've updated the GlassFish default certificate stores.

  • Truststore: If this column has an X, select Use Development Defaults, or click Truststore to configure the truststore that contains the certificate and trusted roots of the server. For the GlassFish keystores, the file is cacerts.jks and the alias is xws-security-server , assuming that you've updated the GlassFish default certificate stores as described in To Manually Update GlassFish Certificates.

    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.

  • Default User: When this column has an X, you must configure either a default username and password, a UsernameCallbackHandler, or leave these options blank and specify a user at runtime. More information on these options can be found at Configuring Username Authentication on the Client.

  • SAML Callback Handler : When this column has an X, you must specify a SAML Callback Handler. Examples of SAML Callback Handlers are described in Example SAML Callback Handlers.

  • STS : If this column has an X, you must have a Security Token Service that can be referenced by the service. An example of an STS can be found in the sectionTo Create and Secure the STS (STS). 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.

  • SSL : To use a mechanism that uses secure transport (SSL), you must configure the system to point to the client and server keystore and truststore files. Steps for doing this are described in Configuring SSL For Your Applications.

  • User in Glassfish: To use a mechanism that requires a user database for authentication, select Use Development Defaults, or add a user to the file realm of GlassFish. Instructions for doing this can be found at Adding Users to GlassFish.

  • Kerberos: This option is only valid for 'Symmetric Binding with Kerberos Tokens' profile. Click Kerberos button to configure the Login Module and Service Principal to be used by client, and if credential delegation should be set. An example showing use of Kerberos Tokens can be found at Example: Kerberos Token (Kerb).

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.

    • Use Development Defaults:

      Select this option to import certificates into the GlassFish keystore and truststore so that they can be used immediately for development. The WSIT message security mechanisms require the use of v3 certificates. The default GlassFish keystore and truststore do not contain v3 certificates at this time. In order to use message security mechanisms with GlassFish, it is necessary to obtain keystore and truststore files that contain v3 certificates and import the appropriate certificates into the default GlassFish stores.

      In addition to importing certificates, when this option is selected a default user is created in the file realm with username wsitUser.

      In a production environment, you should provide your own certificates and user settings, however, in a development environment you may find these defaults useful.

    • Authentication Credentials: Select Static or Dynamic. Select Static to supply a static username and password, or select Dynamic and specify the Username and Password CallbackHandlers. Select Static if you want to fill in the exact user credentials that the client is providing, and which cannot be changed after deployment. Static is useful to developing and testing applications prior to deployment. Select Dynamic to use CallbackHandlers to provide a dynamic way to provide credentials. Dynamic is useful if the credentials need to be obtained from some third party, for example, or if the developer doesn't want to store the user name and password in a configuration file because it might introduce a security risk.

    • Default Username, Default Password : These options are available when Static is selected as the Authentication Credential. 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.

    • Default Username Callback Handler, Default Password Callback Handler : These options are available when the Authentication Credential is Dynamic. If you create JSR-109-compliant web services and web service clients that run under an Application Server container (JSR-109 deployment), the container handles the callbacks and you do not need to configure Callback Handlers of your own. If you are using another container, select the Browse button to select the class implementing the javax.security.auth.callback.CallbackHandler interface.

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

    • Timestamp Timeout: This property specifies the duration(in seconds) for which timestamp should be considered valid. The default is 5 mins(300 seconds).

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

Terms of Use; Privacy Policy; Copyright ©2013-2014 (revision 20140418.2d69abc)
 
 
Close
loading
Please Confirm
Close