Single Sign On with Quickr 8.1 and SPNEGO

Yesterday I was at a customer that is using Lotus Quickr 8.1 (J2EE) and als uses an ISSW asset - the SPNEGO TAI for WebSphere Application Server 6.0 - for WebSphere Portal 6.0. This customer wanted to use the TAI for Quickr too, respectively the underlying Application Server version 6.0.2.17.

And after some troubleshooting and a fix for WAS we finally managed to achieve SPNEGO/Windows Single Sign On for Quickr 8.1!

The only real issue with the product (Quickr) itself was a bug in the redirection after the request had not been intercepted by any TAI where the user was redirected to an error page instead of the login page. This was no specific SPNEGO TAI issue but an issue with the Trust Association Interception in general in the Quickr 8.1 and 8.1.1 underlying App Server, version 6.0.2.17.

However there is a technote and a fix for that known issue if you ever stumble upon this error.

After that fix had been installed - which went pretty smooth - Single Sign On with SPNEGO worked properly. At least in the WebUI but unfortunately not with the connectors.

One of the issues was that with SPNEGO enabled it didn't matter which values we specified for the main UI as user/pwd in the first dialog that comes up when we added a place to the connectors. These values were sent to the server and failed. However, the SPNEGO credentials were also sent along as we were authenticated successfully. But there were other user/pwd dialog boxes that appeared in the usage of the connectors as well. These did not work correctly with SPNEGO enabled.
Currently the Java based connectors (ie ST, Notes 8 Standard, etc) do not work at all when SPNEGO is enabled.

As a workaround to disable SPNEGO for the Connectors we considered two options:
The first (that was tested and finally implemented) was simply to create an additional DNS entry for the same Quickr server and specified this entry in the Connector (ie. web.quickr.intranet.com for the browser and connector.quickr.intranet.com for the connector). The TAI is configured to intercept only requests to a particular URL respectively a host (ie. web.quickr.intranet.com). If a request is sent to a different hostname (ie connector.quickr.intranet.com), the request is not intercepted and thus no Single Sign On happens.

The second option we thought of but did not test yet was to configure the TAI that way, that it uses a filter to exclude the URL used by the Connector respectively only intercept requests for the protected URLs of the web ui, which are URLs that contain /lotus/myquickr. Using the HTTPFilter for the configured server and a filter string "request-url==/lotus/myquickr" should do the job, but as mentioned - we did not test this.

Luckily, Quickr 8.2 is coming soon with official SSO support for the Connectors and it will be backward compatible to Quickr 8.1.1.

Pointing to a specific Activity using the Portal Bookmark portlet

Today we tried to create a landing page for a Portal with integrated Connections. The landing page should contain a link to give feedback. Since it is a PoC we'd like to use an Activity for collecting feedback to demonstrate the various usage possibilites for Lotus Connections. The link to the feedback activity should have been provided in the Bookmark portlet of WebSphere Portal. However, we encountered a minor issue for which we found a solution.

The problem was, that the URL to the Activity contained a comma character respectively the octet encoding of it (%2C). Although this format is conforming with URL RFC 1738 (paragraph 2.2.) the Bookmark portlet refused to accept this URL stating the URL was not valid.

However, we found a workaround for that. We created a Portal URL page pointing to the feedback activity and put this URL page underneath the Activities URL page in the portal page structure so that it remains invisble. We assigned a uniquename to this URL page pointing to the Feedback Activity and created a bookmark in the bookmark portlet that pointed to the Portal URL page for the Feedback Activity. Thats it. The uniquename is required, otherwise this URL page would not be selectable as portal internal page in the Bookmark portlet.

By the way, I like the approach of collecting feedback using an Activity. The users can comment on existing feedback, agree, disagree. The feedback can be given in a structured way, like technical feedback, opinions, enhancement requests, and the users could even post files. The receivers of the feedback can give answers directly to the posts and users could easily subscribe to updates to stay informed about what's going on. And the best of all: it's usable out-of-the-box, we did not need to create a custom feedback form :)

Integrating Lotus Quickr into Connections

This week we configured the integration of Lotus Quickr into Lotus Connections Activities and Communities. We experienced some minor problems of which I like to write here, so you don't step into them, too. First of all, the configuration is quite straight forward and looks more complicated on first glance, than it actually is, so don't be afraid of it.

Activities
How Activities need to be configured, is described in the Infocenter, here. However, we had the problem, that we were not able to connect to the Quickr server that we configured. The reason of that was, that we used a self-signed certificate for the HTTP server, since it was only a proof of concept installation. But first, some words, how the Activities integration works.
For querying the Quickr server for places, Activities uses a REST service of Quickr and since Activities is mainly based on AJAX, the REST request is sent via JavaScript. For security reasons, the JavaScript script can't access the quickr sever directly, since it runs on a different server that the connections server. So the request is delegated to a proxy running on the connections server and the proxy forwards the request to the Quickr server.
However, to send the REST request from the proxy to the Quickr server, the proxy servlet needs to establish an HTTP connection, and since we used SSL for that, the connections was established over HTTPS. The trouble we had was, that the proxy did not trust the self-signed certificate of the Quickr HTTP server, so we needed to import that self signed certificate into the trust store of the WebSphere Application server (described here) the proxy was running on. That was all.

Communities
Different from Activities, the integration of Quickr into Communities requires some more steps. Therefor you need to download the Lotus Connections Connector for Lotus Quickr, and follow the installation instructions. That was straightforward, but it did not work with our setup, unfortunately.
To explain a little bit the setup we used, Connections and Quickr were both running on seperate servers, both with a collocated HTTP Server that performs the forwarding from the standard http ports 80 and 443 to the ports  Quickr is running on in the AppServer, which are for instance 10038 for http. So we configured during the installation of the Connector to use the default ports, 80 and 443 for ssl. What worked in Activities, did not work in Communities.
When we created a new community and checked the both new Quickr integration checkboxes, we experienced an exception, telling us (in the logs) that an URL like this one http://quickr.demolab.com/myqcs/rest/places/feed was not found. The reason for this was, that the Connector searched at the wrong port. For this particular URL the HTTP did no port forwarding, we still need to find out, why not. But anyway, after changing the http port following the instructions in the InfoCenter to port 10038, the integration worked perfectly... and btw. is pretty cool :)