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. ]
C:\>pdadmin
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.

Fixing WebSEAL that suddenly stopped responding to HTTPS

Did it happen to you that your lab WebSEAL instance suddenly stopped working? Everything seems to be up and running, but any regular request to port 444 results in “Internet Explorer cannot display the webpage”? Well, it happened to me several days ago. Testing the same URL in Google Chrome revealed the possible cause – “ERR_SSL_PROTOCOL_ERROR”. Additional test revealed that HTTP traffic on port 81 (which is typically not used) is served correctly.

I’ll save you from reading the frustrating troubleshooting details. The bottom line is simple – the self-signed SSL certificate supplied with IBM WebSEAL expired on August 27, 2011. This is the certificate that is used by default in many labs, including mine. The fix is really simple – if you know where to look and what to do.  Continue reading “Fixing WebSEAL that suddenly stopped responding to HTTPS”