SAML & IBM Connections 5.5 – not a dream team

Hi all,

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:
Relying Party:

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.
(WrappedHttpListenerContext context)
(SamlContext context, MSISSignInResponse response)
(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. SSO token uniqueID not null, but opaque token not found. Need to re-challenge the user to login again.

There is a technote for this describing this issue.

Basically this technote summarizes that this problem is caused by:

“In Websphere Application Server and 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 From on the property was removed.

The property is called “”

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.

One thought on “SAML & IBM Connections 5.5 – not a dream team

  1. Hello Julius,
    this was it. Your Technote was the needed help at Upgrade IBM Connections from CR02 to CR03 in connection with SAML.
    A lot of wasted time, because at IBM support entries the error was not refere to this combination WAS and 5.5 CR03.
    Log entries did not shown realy helpful information. Only via Browserconsole you could see a broken redirect.

    Thanks a lot of and best regards

    Thanks a lot of and best regards

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.