Thursday, July 23, 2009

WAS Integrated Solutions Console log out of Tivoli Access Manager SSO

We have implemented the following
  • Tivoli Access Manager 6.1 for e-Business (base components)
  • TAM WebSEAL 6.1
  • WebSphere Application Server 6.1
  • Deployed Web Portal Manager 6.1 as a plugin for WAS Integrated Solutions Console
  • Configured Trust Association Interceptor Plus(TAI++) for Single Sign-on
  • Configured WAS ISC(Admin Console) and WPM to be utilise TAM's SSO credential
So we have created a WebSEAL junction to access WAS ISC and ultimately access WPM in the drop down menu using WebSEAL SSO credential.
The problem which we have encountered was deciding how to
implement a synchronised logout from WAS ISC and WebSEAL. Native behaviour when clicking the Logout link, ./ibm/console/logout.do, the user is only logged out of the WAS ISC. The problem however is, its not a total logout from WebSEAL SSO session, as you can revalidate into the WAS ISC without manual reauthentication if using the same browser (utilising TAM SSO credential). This problem can be described in more detail on this link http://www.ibm.com/developerworks/tivoli/library/t-tamtai/ (in the Security Issues section, as WebSEAL and WAS authentication are two distinct HTTP sessions which are not synchronised)

There is the option where you can redirect the logout link to use solely the TAM's WebSEAL logout command, pkmslogout, and this will destroy TAM SSO credential and logout of WebSEAL's session. However WAS authenticated session is still logged in, and you may encounter the problem scenario as described at link
http://www.ibm.com/developerworks/tivoli/library/t-tamtai/ in the Security Issues section.

So the solution that we required was to logout from WAS and then WebSEAL session. Using the following link as reference http://publib.boulder.ibm.com/infocenter/ltscnnct/v1r0/index.jsp?topic=/com.ibm.help.lotus.connections.doc/t_secure_with_tam_102.html, we can to this conclusion

(1) Have IBM HTTP web server running
(2) Configure httpd.conf file to include rewrite rules (you can also include RewriteCond if you wanted)
  • RewriteRule /(.*)/logout(.*) /ibm/console/ibm_security_logout?logoutExitPage=../../../pkmslogout [noescape,L,R]
So the above rewrite rule will log the user out of the WAS session, then direct the logout request to the TAM's WebSEAL logout command which will logout of the SSO session.

(3) Ensure also that httpd.conf has the following lines not commented out
  • LoadModule rewrite_module modules/mod_rewrite.so
  • RewriteEngine On
Hope the above information helps.

Monday, July 20, 2009

CloudScape / DB2 Error - Database has exceeded largest log file number 4,194,303

When using Tivoli Directory Integrator to convert and integrate different sources of data, I encountered the following error :-
ERROR XSLAK: Database has exceeded largest log file number 4,194,303.
at db2j.de.b.newException(Unknown Source)
at db2j.ci.g.qm_(Unknown Source)
at db2j.ci.g._t6(Unknown Source)
at db2j.ci.g.checkpoint(Unknown Source)
at db2j.ci.g.recover(Unknown Source)

The appropriate solution that I found was simply increase the max file log id which is detailed in this article, http://osdir.com/ml/apache.db.derby.devel/2005-05/msg00685.html
However with little knowledge of cloudscape and integrator, and much more importantly little patience - I went with a more aggressive approach. Within the ./CloudScape/log directory which contains the log files -
log4194300.dat
log4194301.dat

log4194302.dat
I removed these dat files and restarted the TDI job. Voila! The job kicked off successfully and produced the resulting xml file (or whatever output file) correctly.

NOTE: I left the following files untouched
logmirror.ctrl
log.ctrl