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.
