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.

[ Update (April 2013): How to perform this task with ‘pdadmin’ utility. ]

By default WebSEAL junctions do not require any specific authentication for external access – they just derive the default ACL definition of the WebSEAL. However, this default ACL does not allow access to unauthenticated users. So, efficiently the users have to pass authentication with any available authentication method to gain access rights for the junction that does not need any specific authentication.

Here I will explain how to define unauthenticated junction – a junction that allows access to any user, including users that did not pass WebSEAL authentication at all. In fact, creating unauthenticated junction in WebSEAL is super-easy and super-simple when you are experienced WebSEAL professional. If you are a newbie or WebSEAL administration is not among your main tasks, the logic of this flow is not so trivial to guess (or even recall).  Continue reading “Unauthenticated Access to WebSEAL Junctions” →