The following diagram and detailed steps illustrate the process flow for external authentication interface authentication. The components of this example process flow scenario include:
- WebSEAL.
- Junctioned server with an external authentication application that uses the external authentication interface.
- Authentication process is initiated.
There are many possibilities for initiating the authentication process. A typical example:
- An unauthenticated user requests a protected resource.
- 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.
- 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.
Other examples of initiating the authentication process can include:
- Manually typing an appropriate link to the external authentication application.
- Signon requirement in a CDSSO environment.
- Cached page.
- In an IBM® Tivoli® Federated Identity Management scenario, the user is redirected to the external authentication application from a service provider, with the goal of having an identity provided for that user.
Note: A hidden configuration option enables you to give priority to an EAI header to redirect a successful login to a URL. To enable this feature, add the following option and value to the [eai] stanza:eai-redir-url-priority = yes - Authentication request and response exchange.
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 URL could, for example, include a query string that indicates the login task, such as state=perform-login. This final URL is specified, in part or whole, in the WebSEAL configuration file as the trigger URL. WebSEAL examines each request for this trigger URL.
If the trigger URL is detected, WebSEAL examines the corresponding response for authentication data located in HTTP headers (specified in the WebSEAL configuration file).
WebSEAL supports EAI logout. An HTTP header returned from the EAI enables it to instruct WebSEAL to logout a session. The header emulates the pdadmin server task command line input, and therefore is analogous to the hidden WebSEAL pdadmin command of the same name. The syntax for the header is am-eai-server-task: terminate session <user-sess-id>, where terminate session is a non-translatable keyword pair, and <user-sess-id> is a user session ID of the same format and contents as that used to perform the terminate session command using pdadmin.
Example exchange 1:- The user clicks a submit link on a custom login page. This link is the trigger URL.
- The recognition of the trigger URL in the request causes WebSEAL to look for authentication data in the corresponding response.
- The external authentication application authenticates the user and, in its response, populates the special HTTP headers with authentication data.
Example exchange 2:- The external authentication application requires several exchanges with the user to receive the required login information.
- Each request to the external authentication application uses the trigger URL. Therefore, for each response, WebSEAL looks for authentication data.
- WebSEAL examines each corresponding response for authentication data returned from the external authentication interface in HTTP headers.
- When no authentication takes place, these headers are empty in each response. WebSEAL continues streaming the requests and responses without taking any action.
- After several exchanges, the external authentication application receives all the login information it needs. The external authentication application authenticates the user and, in its final response, populates the special HTTP headers with authentication data.
Example exchange 3:- The external authentication application requires several exchanges with the user to receive the required login information.
- Each request to the external authentication application uses a URL that does not match the trigger URL. Therefore, for each corresponding response, WebSEAL does not look for authentication data
- WebSEAL streams the requests and responses without taking any action.
- The final request to the external authentication application uses the trigger URL.
- The recognition of the trigger URL in this final request causes WebSEAL to look for authentication data in the corresponding response.
- The external authentication authenticates the user and, in its final response, populates the special HTTP headers with authentication data.
- Authentication response.
WebSEAL examines the corresponding response and finds the authentication data in the HTTP headers.
- WebSEAL uses the authentication data to build a credential for the user.
- WebSEAL sends a response to the user using the following precedence:
- If automatic redirection is enabled, the user is redirected to the location specified in the WebSEAL configuration file.
- If the response from the external authentication
application contains the streaming flag, WebSEAL streams the original
response to the client.
See External authentication interface - authentication flags.
- If the initial request was cached, the request is reprocessed for the user.
- If the response from the external authentication application contains
a redirection URL header, the user is redirected to the location specified
by that URL.
See External authentication interface-specified redirection.
- Otherwise, WebSEAL responds with the standard login_success.html page.