Authentication through 401 WWW-Authenticate

Use this scenario as an example where the authentication information is provided as an HTTP header, for example, basic-authentication.

This flow uses Local Response Redirects where requests to any page that requires an authenticated user is intercepted and redirected to the junctioned EAI application for authentication.

The junction that provides this EAI application must be created with HTTP Basic Authentication Header set to ignore.

Assume the following configuration entries have been set in the WebSEAL configuration file.

[ba]
ba-auth = none

[eai]
eai-auth = https

[eai-trigger-urls]
trigger = /jct/cgi-bin/eai

[acnt-mgt]
enable-local-response-redirect = yes

[local-response-redirect]
local-response-redirect-uri = [login] /jct/cgi-bin/eai

The traditional flow is shown as follows: The /index.html file is just an example. It can be any document from WebSEAL or its junctions that require an authenticated session for access.

To configure WebSEAL to internally process 302 operations, first specify the maximum number of 302 operations it can sequentially follow. A value of 2 is suitable for typical scenarios:

[server]
maximum-followed-redirects = 2

Secondly, configure WebSEAL to process 302 redirects internally for any request that results in a Local Response Redirect with the following entry:

[server]
follow-redirects-for = !LRR!

This configuration avoids the initial Local Response Redirect 302 (shown at point 1). The client can now receives the 401 WWW-Authenticate header for /index.html instead of a redirect to the EAI URL. So the client sends the authorization header with a GET for /index.html.

Thirdly, set WebSEAL to process redirects internally for any request that would result in a 302 redirect back to the same URL that was originally requested (shown at point 2). To achieve this, add the following configuration entry:

[server]
follow-redirects-for = GET /jct/cgi-bin/eai*

The original request from the client was for /index.html. In this flow, WebSEAL internally redirects the client to /index.html. So the resulting page content that is returned from WebSEAL matches what the client is expecting to receive. Relative URLs in this page will operate as expected.

The final flow is shown as follows: Two sequential 302 operations are internally processed by WebSEAL (shown at 3 and 2) in the flow, which is why the value of 2 was used for the maximum-followed-redirects entry.

Parent topic: External authentication interface for mobile applications