Securing Lotus Connections With WebSEAL

There are a few documents on the web that try to explain how to integrate Lotus Connections with WebSEAL and they do actually work to a certain extent. However, there are holes in their explanations that prevent the full rich experience of a Lotus Connections environment when fronted with a WebSEAL.

Here's how to "plug" those holes for a Lotus Connections v2.5 and Tivoli Access Manager v6.1 infrastructure.

Firstly... I should point out that the integration guide written by En Hui Chen is excellent and was used as the basis for this guide. His guide can be found at http://www-10.lotus.com/ldd/lcwiki.nsf/page.xsp?documentId=65A226C20BEC2302852576B100410A04&action=openDocument

Lotus Connections Data Flow
To understand why WebSEAL and Connections should be configured the way they are, it is important to understand how the components communicate with and through each other. Fundamentally, a user's experience with Connections is not constrained to the HTTP traffic bouncing between a browser and (ultimately) the Connections applications. Instead, we need to be mindful of Ajax components being rather chatty with the back end as well as inter-service communications across Connections applications. When we introduce WebSEAL, we need to ensure that the traffic is being routed appropriately as such:

The Holes

Hole 1
The connectionsAdmin account must be an account known to TAM. The following pdadmin commands should therefore be called to ensure that the account is imported correctly and valid:

pdadmin> user import connectionsAdmin {connectionsAdmin dn}
pdadmin> user modify connectionsAdmin account-valid yes

Hole 2
This might not necessarily be called a hole, but rather an amalgamation of information on the Lotus Wiki and the information on the IBM Infocenter sites. However, the following objects required the Connections ACL to be applied to them:

acl attach /WebSEAL/{webseal}/profiles/dsx {connections_acl}
acl attach /WebSEAL/{webseal}/communities/dsx {connections_acl}
acl attach /WebSEAL/{webseal}/blogs/blogsapi {connections_acl}
acl attach /WebSEAL/{webseal}/blogs/blogsfeed {connections_acl}
acl attach /WebSEAL/{webseal}/files/basic/anonymous/atom {connections_acl}
acl attach /WebSEAL/{webseal}/files/form/anonymous/atom {connections_acl}
acl attach /WebSEAL/{webseal}/files/wl {connections_acl}
acl attach /WebSEAL/{webseal}/activities/images {connections_acl}

Hole 3
This probably isn't a hole either, to be honest. Instead, it's best to see it as a re-iteration or re-clarification.
The LotusConnections-config.xml file should be updated to contain the following:

<dynamichosts enabled="true">

<host href="http://fully-qualified-host-name" ssl_href="https://fully-qualified-host-name">

</dynamichosts>

Also, ensure that the static href, static ssl_href and interService URLs for all services are pointing at the WebSEAL cluster:

<sloc:static href="http://fully-qualified-host-name" ssl_href="https://fully-qualified-host-name" />

<sloc:interservice href="https://fully-qualified-host-name" />

Note, the fully-qualified-host-name MUST be set to the host name where the WebSEAL is to be found.

Hole 4
Lotus Connections applications will attempt to open server to server communications with other Lotus Connections applications via Tivoli Access Manager. If forms-auth has been set to https in the webseald-.conf file, then the signer certificate for WebSEAL client-side SSL communications should be added to the WebSphere trust stores. In addition, the LotusConnections-config.xml file should be updated to contain the following:

<forceconfidentialcommunications enabled="true"></forceconfidentialcommunications>

Following En Hui Chen's guide and applying the "plugs" above should get you a perfectly working TAM-Lotus Connections environment. If not, drop me a line... I may be able to help. Failing that, have a chat with @dilftechnical who provided some invaluable Lotus Connections insight while diagnosing the issues we faced during integration.