A week ago I had to investigate whether it is possible to configure multiple EAIs in WebSEAL, when each one provides different authentication level. While configuration of several EAIs is pretty simple – all that you need is one trigger URL per EAI, and this is perfectly supported – placing each one of the on the own authentication level does not look trivial. The definition of authentication level per authentication method in WebSEAL is implicit, by the order of the authentication methods in the list.

For example, the list below defines password authentication to be level 1 and EAI to be level 2:

[authentication-levels]
level = unauthenticated
level = password
level = ext-auth-interface

But how do you define EAI to act as both first and second method? Well, simple – but not so intuitive:

[authentication-levels]
level = unauthenticated
level = ext-auth-interface
level = ext-auth-interface

Note that here EAI is mentioned twice – both as a first and as a second authentication level!

Additional missing piece of the puzzle is to tell WebSEAL which one of your EAIs represents each authentication level. This is solved via special “am-eai-auth-level” HTTP header from your EAI back to WebSEAL upon successful authentication, in the same way you send the username:

HTTP/1.1 200 OK
Date: Thu, 28 Jun 2012 12:00:00 GMT
am-eai-user-id: john
am-eai-auth-level: 2
Content-Type: text/plain
Content-Length: ........

Now you have to check with EAI should be invoked when the user comes to the login page. This information is available to your login page via %AUTHNLEVEL% macro. The processing can be easily done via JavaScript on the static logic or using server-side processing when LRR is enabled.