Coding IBM Collaboration Solutions

My team manages a fair amount of server configurations. We support three major versions of Portal integrated with Lotus Domino, QuickPlace/Quickr, and Sametime. So it's easy to see that the number of servers and their configurations grow quite quickly.

At one time, we had three LDAP vendors (Domino LDAP, IBM Directory Server, and Active Directory) paired with its own Portal server. QuickPlace and Sametime were then paired with a respective Portal and LDAP server. All in all, at a minimum that makes 15 servers.

To consolidate, we use Portal LDAP federation. The Portal Infocenter makes a fair attempt at explaining this; however, I find the following technote much more helpful: How to configure WebSphere Portal for multiple LDAP servers. This allows us to use three versions of Portal federated to three LDAP servers.

Technically, you can further reduce the configuration overhead by federating the three LDAPs to QuickPlace by configuring QuickPlace to use Domino directory for authentication and setting up directory assistance to the various LDAP servers. The Sametime server's stconfig.nsf databases's LDAP documents can be copied to federate the LDAP servers with Sametime. Be aware that if you copy the LDAP documents, they should point to different LDAP server FQDNs. The LDAP servers can physically reside on the same server, but you should set up DNS or local hosts files to separate them out as ldap1.ibm.com, ldap2.ibm.com, ldapN.ibm.com. I assume that Sametime stores the LDAP settings using the LDAP FQDN as a key so multiple documents with the same FQDN will overwrite each other.

We tried the above QuickPlace and Sametime configurations with some success but eventually opted to use a single IDS LDAP. Ultimately, you do want to keep the environment as simple as possible if you can. This always limits the likelihood of a "less than tested" issue from arising. But if you're pressed for space, servers, or the adventureous type, some form of federation may assist you in server consolidation.[Read More]

I was reminded today by a colleague of a subtle nuance of Lotus Sametime and WebSphere Portal integration. For those not familiar with this area of integration, WebSphere Portal directly uses the STLinks toolkit from the Sametime server to provide awareness and chat capabilities with the Portal offering. The Sametime Links Toolkit (STLinks) has been released for some time now, and little has changed with respect to WebSphere's usage of the toolkit except for one seemingly minor detail.

WebSphere Portal initiates the Sametime applet (STLinks) which is responsible for direct Sametime server communication via the toolkit's Javascript function, writeSTLinksApplet(). In Portal V5 and V6, this appears similar to the following in the HTML page source:

writeSTLinksApplet("uid=idsuser1,cn=users,dc=ibm,dc=com", "nHrxIukUwZxbTDDDfqkx7PU8SM3UBjbt25uzMTfLAkbqTZUPuu3ULaHW4dtJtBGhYSl4SvKIK1OA6Oj
R5/MGCspSPl4nlD91dqRmNOhhxwJDib59nv4YlZZnjxgWHHk4GBJqsMnc9dZaTLd776FDxDA3ImGFKBWpeExrmDZJHDq7+zTDN0pZGe86Qhr0/g1ZxJOJq8R7nl+3Cj5qOI+jL
0IyeabmiQ3LhzIL48x/OXyw06uKHhVm2OxSBLBbXxv/XDU+hBlyxclBHiTrBp9WV7A3mf4kbFql1Hxg1e7kMutJRw3eFDjx1B+yWCKmK7FO", true)

Depending on your LDAP directory, the case of the LDAP user's distinguished name might be the lower case uid=idsuser1,cn=users,dc=ibm,dc=com as in the example above or mixed case UID=idsuser1,CN=users,DC=ibm,DC=com. This minor detail has an impact on WebSphere Portal V6's ability to easily integrate Sametime. In Portal V6, the distinguished name that is used as the first argument in the writeSTLinksApplet function is always lower case. WebSphere does this by default (designed behavior), and the result is the example shown above. If the case in LDAP differs, you'd ideally want Portal to use the following STLinks function call:

writeSTLinksApplet("UID=idsuser1,CN=users,DC=ibm,DC=com","nHrxIukUwZxbTDDDfqkx7PU8SM3UBjbt25uzMTfLAkbqTZUPuu3ULaHW4dtJtBGhYSl4SvKIK1OA6Oj
R5/MGCspSPl4nlD91dqRmNOhhxwJDib59nv4YlZZnjxgWHHk4GBJqsMnc9dZaTLd776FDxDA3ImGFKBWpeExrmDZJHDq7+zTDN0pZGe86Qhr0/g1ZxJOJq8R7nl+3Cj5qOI+jL
0IyeabmiQ3LhzIL48x/OXyw06uKHhVm2OxSBLBbXxv/XDU+hBlyxclBHiTrBp9WV7A3mf4kbFql1Hxg1e7kMutJRw3eFDjx1B+yWCKmK7FO", true)

The above example is the behavior in Portal V5 - not so in Portal V6. Portal V6 changes all distinguished names to lower case. If you've ever designed your own application to use STLinks, the immediate response is, "so just change the case". This brings us to the relatively unknown nuance. The second argument in the writeSTLinksApplet function is the LTPAToken. The LTPAToken is a single sign on mechanism which is an encoded string of the LDAP realm, user's distinguished name, and expiration time. If attained from Portal V6, the token contains a distinguished name that is - you guessed it - lower case. When the Sametime server logs the user in using the writeSTLinksApplet call it will compare the name sent in the first argument and the name decrypted from the LTPAToken. If they differ (in case for example), no login to Sametime occurs. If you're troubleshooting but using the user's password as an argument, you might notice that you achieve awareness successfully. Again, the issue with case occurs only when using the LTPAToken.

This is a fairly long post for the simple fact that if your users in LDAP contain mixed case characters (Domino LDAP and Active Directory specifically), you will require a case fix applied to Sametime when integrated with Portal V6. If using Sametime 7.5.1+, this is trivial as a workaround is inherent in the product. If you're using any previous version of Sametime, you may need to contact support for added assistance. If using Sametime 7.5.1+, update the stlinks.js file's STlinksCaseSensitive variable to :

var STlinksCaseSensitive=false;

Append the AWARENESS_CASE_SENSITIVE=0 argument to the STLINKS_VM_ARGS property and add the AWARENESS_CASE_SENSITIVE=0 property value pair to the [Config] section. For example,

[STLinks]STLINKS_VM_ARGS=-Xmx128m -Xgcpolicy:optavgpause -Xrs -DAWARENESS_CASE_SENSITIVE=0

[Config]AWARENESS_CASE_SENSITIVE=0

Hope this helps prevent some unnecessary troubleshooting.[Read More]