How to configure multiple EAIs with different authentication levels in WebSEAL

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:

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:

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.

IBM Tivoli Access Manager for e-business and WebSEAL Resources

After posting another WebSEAL HOWTO recently, I feel it is the right time to post my collection of WebSEAL-related resources and forget about the WebSEAL for a while.

IBM Tivoli Access Manager (TAM) for e-business is positioned by IBM as an end-to-end security solution for e-business, focused on providing robust, policy-based security to a corporate web environment. The web security components of TAMeb are WebSEAL (reverse proxy web server that performs authentication and authorizations; typically used for DMZ external access to backend content servers) and Plug-in for Web Servers (plug-in that secures web servers; typically used for internal access). Continue reading “IBM Tivoli Access Manager for e-business and WebSEAL Resources”

Unauthenticated Access to WebSEAL Junctions

[ 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”

How to turn on debug log in WebSEAL

You can turn on debug logging with “trace” utility from “pdadmin” shell via “server task” call. Here is the general format of the call:

server task <instance>-<host> trace set <component> <level> file path=<path>

The parts in the angle brackets should be replaced with appropriate values:

  • <instance> – the name of WebSEAL instance
  • <host> – hostname of the server that runs WebSEAL
  • <component> – name of the component to turn logging on for (see below)
  • <level> – log level to use (1 to 9, where 1 is the most detailed; use 0 to turn logging off)
  • <path> – filename of the log file to fill with the information

The list of the components can be obtained with “trace list” command. Among the useful WebSEAL-related components:

  • pdweb – trace all WebSEAL-related information
  • pdweb.debug – list of HTTP header going trough WebSEAL
  • pdweb.snoop – same, but including message body
  • pdweb.snoop.client – same, but only for data sent between WebSEAL and the web client
  • pdweb.snoop.jct – same, for data sent between WebSEAL and the actual web servers (aka “junctions”)
In the example below you can see how to turn on debugging of the web traffic that goes through WebSEAL. The log will go to “C:\pdweb.debug” file. [ Update (April 2013): How to open the ‘pdadmin’ shell. ]
pdadmin> login
Enter User ID: sec_master
Enter Password: ********
pdadmin sec_master> server task default-webseald-tameb trace set pdweb.debug 2 file path=C:\pdweb.debug
pdadmin sec_master>

You can read more about “server task trace” in the TAMeb documentation.