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.
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.
