182 Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0
5.1 External authentication interface
Tivoli Access Manager WebSEAL and Web Server Plug-in both support the
externalization of authentication through an HTTP interface. This technology is
known as the
external authentication interface (EAI). The EAI is an alternative
way to customize authentication when the authentication information is passed in
HTTP messages. It allows a back-end application server to perform the
authentication of a user (with the HTTP messages passing through
WebSEAL/Web Plug-in) and then, upon successful authentication, return an
identity to WebSEAL/Web Plug-In using some pre-defined HTTP headers. A
generic flow is depicted in Figure 5-1.
By allowing an application server to perform an authentication, virtually any
desired authentication strategy can be implemented. Since the interface is
HTTP, the back-end application can be written in any language that supports
communication via the HTTP protocol. This is an advantage over the external
authentication C API (previously known as CDAS) that must be written
exclusively in C. The external authentication C API interface is still, however, the
only method for performing non-HTTP authentication such as client certificate
Figure 5-1 External authentication interface
The external authentication interface could return a Privilege Attribute Certificate
(PAC) which could then be used to build the credential.
There are some implications to externalizing authentication outside of the
standard WebSEAL/Web Plug-in password module. The password module in
WebSEAL/Web Plug-In provides for maximum failed login attempts, password
Chapter 5. Programming 183
lifetime checks, and a password change function. All of these functions will need
to be duplicated if using an external authorization interface.
External authentication interface process flow
Figure 5-2 depicts the process flow for an EAI authentication.
Figure 5-2 External Authentication Interface process flow
As we already mentioned, this new interface allows authentication to be
performed by a back-end application being accessed over a junction using
HTTP(S), then the authenticated identity is sent to WebSEAL or WebPI server in
the header of an HTTP response. In detail, the process follows these steps:
1. The authentication process is initiated.
There are many possibilities for initiating the authentication process. A few
typical examples are:
a. An unauthenticated user requests a protected resource.
184 Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0
b. WebSEAL intercepts the request and returns a redirect to a customized
login.html response page. The login.html page is customized to contain a
submit link to the external authentication application. Alternatively,
WebSEAL can be configured to redirect all requests for pages (including
the login page) directly to a page generator which is part of the EAI
Note that the EAI application is assessed over a junction and must be
available to unauthenticated users. An appropriate Access Manager
security policy (for example, an ACL) needs to be configured to allow
unauthenticated users to access this page.
c. The user provides login information (user name and password) on the
form and clicks the submit link to send the data to the external
2. Authentication request.
The process of authentication might require a number of exchanges between
the external authentication application and the client. Exchanges are
streamed through (not intercepted) by WebSEAL.
The final authenticating request to the external authentication application
must be directed to a distinct URL. This POST URL is configured in
WebSEAL as an EAI
trigger URL because the EAI might return an
authenticated identity in response to this POST.
In this case, the EAI application does not return an EAI message. Instead it
has decided that this user must also provide some secondary authentication,
so it returns another form to the client. WebSEAL sees that this is not an EAI
message so it is forwarded to the client.
3. Authentication response.
The client completes the additional challenge and again POSTs it to the EAI
application (via WebSEAL). WebSEAL again matches a
trigger URL. This
time authentication is complete and so the EAI application responds with an
EAI message that contains the authenticated identity.
4. WebSEAL uses the authentication data to build a credential for the user.
WebSEAL spots the EAI message and processes the identity information it
contains to build an authenticated session. The user is now authenticated and
can be directed to the resource they originally requested.
5. WebSEAL sends a response to the user following the algorithm illustrated in
a. If automatic redirection is enabled, the user is redirected to the location
specified in the WebSEAL configuration file.
b. If the initial request was cached, the request is reprocessed for the user.