last week we had to fight with an activation of SAML on a IC 5.5 CR3 environment.
The setup was:
- IBM Connections 5.5 CR3 as test instance
- ADFS Server 3.0 (I know… it is only tested with ADFS 2.0 – but works with 3.0 too)
We followed the instructions from the IBM Connections Knowledge Center. Smooth setup everything standard procedure. When testing this setup, the redirect to the IdP was initiated. After logging into the IdP the browser was redirected to IBM Connections ACS app. But then a loop started. IdP – Connections – IdP – Connections – IdP …Just until the ADFS Server detected this look and cancelled the request (from the ADFS error log):
Encountered error during federation passive request. Additional Data Protocol Name: Saml Relying Party: https://connections.server.com/samlsps/acs Exception details: Microsoft.IdentityServer.Web.InvalidRequestException: MSIS7042: The same client browser session has made '6' requests in the last '2' seconds. Contact your administrator for details. at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.UpdateLoopDetectionCookie (WrappedHttpListenerContext context) at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.SendSignInResponse (SamlContext context, MSISSignInResponse response) at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest (ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler) at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext (WrappedHttpListenerContext context)
Enabling traces on both InfraCluster & UtilsCluster showed us the following error message:
[8/15/17 9:06:59:669 CEST] 000000fb ContextManage 3 Opaque token lookup via mbean will not occur. [8/15/17 9:06:59:669 CEST] 000000fb ContextManage 3 Exception getting opaque token from originating server. com.ibm.websphere.security.auth.WSLoginFailedException: SSO token uniqueID not null, but opaque token not found. Need to re-challenge the user to login again. at com.ibm.ws.security.auth.ContextManagerImpl.getOpaqueTokenFromCacheOrOriginatingServer(ContextManagerImpl.java:1924) at com.ibm.ws.security.auth.ContextManagerImpl.login(ContextManagerImpl.java:3483)
There is a technote for this describing this issue.
Basically this technote summarizes that this problem is caused by:
“In Websphere Application Server 126.96.36.199 and 188.8.131.52 there are two settings which can contradict each other in certain circumstances if they are both set to true. ”
Addition to this: The properties IBM talks about is also active in WAS 184.108.40.206. From 220.127.116.11 on the property was removed.
The property is called “com.ibm.websphere.security.disableGetTokenFromMBean”
.... com.ibm.websphere.security.disableGetTokenFromMBean Use this property to disable the outbound SOAP call to retrieve the subject from the originating server when Single Sign-On is enabled. Typically, when Single Sign-On is enabled, and an inbound request needs to be authenticated, the receiving server attempts to retrieve the authentication from the originating server. The connection between the sending and receiving servers never times out during this callback process. When this property is set to true, the receiving server does not attempt to authenticate the inbound request. ....
And it is set to true by default. This caused the loop.
Setting this to “false” and restarting the cell, SAML authentication immediately started working.
It would be very helpful to get a short link in the IBM Connections 5.5 Knowledge Center to the above technote! This would have saved quite some time.