Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0

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:

[forms-sso-login-pages]

login-page-stanza = xxxxx

#login-page-stanza = aaaaa

#login-page-stanza = bbbbb

[xxxxx]

login-page = regular-expression-page-match

login-form-action = regular-expression-form-match

gso-resource = gso-target argument-stanza = yyyyy

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