Here are some useful links to various WebSEAL concepts:
Posts Tagged ‘WebSEAL’
Posted by January 24, 2013on
Posted by June 28, 2012on
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: ........
Posted by January 15, 2012on
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). Read the rest of this entry »
Posted by January 8, 2012on
[ 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). Read the rest of this entry »
Posted by September 8, 2011on
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”)
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.