Chapter 4. Configuration and customization 159
The login form from the back-end application can be filled in with a variety of
information from WebSEAL, such as:
򐂰 Static text
򐂰 GSO user name and password (see 4.9.1, “Tivoli Global Sign-On (GSO)
lockbox” on page 155 for more information)
򐂰 Values contained within a user’s credential
In order to use forms-based single sign-on, the back-end application’s login page
must be uniquely identifiable. Also, client-side scripting can be used to validate
input data, but it must not modify the input data. The junction where the
authentication request is directed must be the same junction where the login
page is returned.
Forms single sign-on (FSSO) configuration
Configuration of forms single sign-on (FSSO) is done in two steps:
1. Create a configuration file to specify how the login form is to be recognized,
completed, and processed.
The forms single sign-on configuration file is custom-created by the
administrator and can be saved in any location. The configuration file must
begin with the [forms-sso-login-pages] stanza and has the following format:
login-page-stanza = xxxxx
#login-page-stanza = aaaaa
#login-page-stanza = bbbbb
login-page = regular-expression-page-match
login-form-action = regular-expression-form-match
gso-resource = gso-target argument-stanza = yyyyy
name = method:value
2. Enable forms single sign-on by configuring the appropriate junction with the
–S option (which specifies the location of the configuration file).
4.9.3 Single sign-on using HTTP BA headers
A junction can be set up to specify client identity information in BA headers. This
section discusses the possible solutions for creating single sign-on
configurations across WebSEAL junctions using the –b options. The –b option
allows four possible arguments: filter, supply, ignore, gso.
160 Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0
Passing an unchanged basic authentication header
WebSEAL can be configured to pass the received basic authentication data
unchanged to the junctioned application. If Access Manager and the application
share the same LDAP registry, Access Manager authenticates a user against the
same LDAP attributes as an application performing a regular LDAP bind (that is,
using a main user ID and password). In this case, there is no need to maintain
the GSO attributes of a user, and the main password may be encrypted.
However, basic authentication is the only available authentication method used
by WebSEAL because WebSEAL has to obtain the BA header values in order to
pass them through.
The –b ignore option instructs WebSEAL to pass the original client basic
authentication (BA) header straight to the back-end server without interference.
Because sensitive authentication information (user name and password) is
passed across the junction, the security of the junction is important. An SSL
junction is most appropriate.
Junction without BA authentication information
This may be useful if WebSEAL does all of the authentication and authorization
and there is no need to forward any information to the back-end servers.
This scenario seems applicable either for servers without any reliable security
functions or where there is no need for extra back-end authentication and
authorization (for example, providing only static Web pages). Nevertheless, this
approach requires full trust toward WebSEAL, and the back-end servers should
be configured to accept only incoming requests from WebSEAL.
Junction needs to be configured with the -b filter option to remove all basic
authentication header information from any client requests before forwarding the
requests to the back-end server. In this scenario, WebSEAL becomes the single
security provider.
If the back-end server needs to have some client information, this option can be
combined with the –c option to insert Tivoli Access Manager client identity
information into HTTP header fields. This option is described in 4.9.4, “Supplying
identity information in HTTP headers” on page 161.
Providing client identity with a generic password
This scenario assumes that the back-end server requires authentication from a
Tivoli Access Manager identity. By mapping a client user to a known Tivoli
Access Manager user, WebSEAL manages authentication for the back-end
server and provides a simple domain-wide single sign-on solution.

Get Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0 now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.