My online notepad
A year ago I posted an explanation about unauthenticated junctions for WebSEAL. Let’s do the similar task with pdadmin – create a "passthrough" ACL for WebSEAL.
[ Note: This post assumes that you have authenticated ‘pdadmin’ session opened! ]
First, we will create a fresh ACL:
pdadmin sec_master> acl create webseal-passthrough
pdadmin sec_master> acl show webseal-passthrough
ACL name: webseal-passthrough
Description:
Entries:
User sec_master TcmdbsvaBRl
pdadmin sec_master>
This is the first in the series of posts that explain how to complete various tasks with ‘pdadmin’ command line tool. All versions of IBM Security Access Manager for Web (formerly known as IBM Tivoli Access Manager for e-Business) come with this tool, which sometimes makes it much more useful than Web Portal Manager UI. Here I will cover the basics – how to open the pdadmin shell and how to authenticate yourself.
There are several possible ways to get to the pdadmin prompt.
The first thing you have to do after the pdadmin prompt was opened is to authenticate your session to the server. This task is pretty straightforward.
pdadmin> login Enter User ID: sec_master Enter Password: ******** pdadmin sec_master>
Note that there is no need to issue explicit login command when working via HTTP API, since the authentication credentials are specified in the dedicated section of the HTTP payload.
Here are some useful links to various WebSEAL concepts:
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.
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”