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 |
Keystore: If this column has an X, 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 as described in To Update GlassFish Certificates.
Truststore: If this column has an X, 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 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 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. Instructions for doing this can be found at Adding Users to GlassFish.
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.
In the Projects window, expand the node for the web service client.
Expand the Web Service References node.
Right-click the node for the web service reference for which you want to configure security options.
Select Edit Web Service Attributes.
Select the WSIT tab to display the WSIT options.
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.
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.
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).
Creating a SAML Callback Handler is beyond the scope of this document. However, the following web pages may be helpful for this purpose:
A client-side configuration, which includes a SAML Callback Handler, can be viewed at the following URL:
An example of a SAML Callback Handler can be viewed and/or downloaded from the following URL:
An example application in this tutorial that uses a SAML Callback Handler can be found in Example: SAML Authorization over SSL (SA).
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; }