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

Keystore: If this column has
an X, 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 as described in To Update GlassFish Certificates.

Truststore: If this column
has an X, 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 as described in To Update GlassFish Certificates.

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.

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

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.

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.

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.

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.

Figure 7–3 WSIT Configuration - Client - Username
Authentication

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.

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.