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.
5 comments:
We are very interested in getting SPNEGO to work with Quickr 8.1.1 for Portal, and I have a few comments/questions.
1) As far as we know Lotus Quickr 8.2 is a Domino only version and no major portal release is currently planned. To get SPNEGO working "out-of-the-box" you need WebSphere Application Server 6.1 and Quickr 8.1.1 unfortunately only runs 6.0.2.x. So as far as we know no Quickr on 6.1 (i.e. no SPNEGO connector working version) on the horizon. Or?
2) We have a Portal 6.1 running an intranet. Could we enable SPNEGO on this and set up LTPA SSO between Portal 6.1 and Quickr 8.1.1? So basically a users goes to the Portal 6.1 and gets automatically authenticated and then hits a quickr link to go to quickr. Would this work? And/Or would it break the quickr connectors?
@Christian
Re: 1) Yes, Quickr 8.2 is more a Domino upgrade, nevertheless the changes in the connector apply to both versions (J2EE and Domino) and the Quickr 8.2 connector will support SSO using SPNEGO. To use it with Quick 8.1 (J2EE) you will still need a custom SPNEGO TAI for WebSphere AppServer 6.0 (like the one from ISSW mentioned in the post, which IBM ISSW provides as a costing service offering). Though, these information are without guarantee, I did not test the Quickr 8.2 Connectors with Quickr 8.1 AND SSO.
Re: 2.) This should definitely work as long as both system are in the same LTPA domain. The Quickr conectors should be not affected by the LTAP SSO and work as usual (since the Quickr URL is not an SPNEGO TAI intercepted URL)
Hi
We have developed jsr 168 portlets with jre 1.5 features,Now we need to deploy the portlets in Quickr 8.1.0 what should we do.
Please help us
Hello,
Is there any good documentation on the steps for configuring SPNEGO for Q8.1/Portal 6.0? We are configuring it on another Portal 6.1 however I keep running into an IBM ISSI solution that there appears no documentation on which may or may not require custom TAI configuration.
Thanks! Mike
SPNEGO with Q8.1 requires a custom TAI. IBM ISSL has developed this and you need to contact IBM for price and availability.
Post a Comment