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

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

authentication.

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

EAIWebSEAL/WebPI

Build

Credential

Gather

Authentication

Data

Session Cache

Verify/Process

Data

Return Access

Manager User

ID

HTTP

Browser

Access Manager

User ID

(Auth Level)

(Attributes)

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

application.

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

authentication application.

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

Figure 5-3.

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.