This morning I helped a customer because they couldn’t make the beta of the OnTime Group Calendar for IBM Connections work and it turned out to be a Single-Sign-On issue. For the OnTime widgets to work we require SSO between Websphere Application Server and Domino which is trivial to set up. Simply export the SSO keys from Websphere using the Integrated Solution Console (ISC) and import them into the SSO document in Domino Directory. In Websphere Application Server terms this is called cross-cell SSO and is very easy to set up.
After doing this SSO still didn’t work and right of the bat I suspected the good ol’ “multiple O= identifier” issue. The issue is when you incorrectly configure federated repositories and a username is reported by ISC with an extra organization identifier e.g. I would be “CN=Mikkel Flindt Heisterberg,o=IntraVision,o=IntraVision” and not simply “CN=Mikkel Flindt Heisterberg,o=IntraVision” the latter of course being correct. While WAS (and IBM Connections) will work just fine with that type of configuration is can cause SSO not to work correctly or only work when the user authenticates to Domino first the problem being that the DN that WAS sticks into the LtpaToken isn’t valid in Domino.
Verifying the names is easy using “Users and Group/Manage Users” in the left hand menu in ISC.
After reconfiguring federated repositories and restarting Websphere Application Server SSO functioned and the customer was back to using the OnTime Group Calendar widgets.
2 thoughts on “Watch the names when doing SSO between WAS and Domino”
Thanks for the info!
If the user’s DN is different in Domino and WAS (used MS AD as a federated repository), is there a way to achieve SSO using LTPA? Can I set user’s UID in the LTPA tokens instead of DN? Thanks.
Yes. In Domino there is a setting in the SSO document to get the username from another LDAP property and likewise in Websphere.
Comments are closed.