Service Provider(SP) initiated logon question.

We have successfully implemented an idP initiated logon.

On Security Verify Access we have defined the following:

1) idP Reverse Proxy

2) idP Federation module

3) SP Reverse Proxy.

on an external windows server is the SP behind the RP.

I have attached an unauth ACL to the junction that poins to the SP.

When I attempt to access this junction the SP creates a SAML 2.0 AuthnRequest that includes an ID and forwards to the idP.

The authentication works properly, the mapping of the user to SAML works properly. The issue is the InResponseTo is missing in the response.

Have I missed a setting on the idP or idP partner definition?

Thanks

I'm not sure what is meant by "on an external windows server is the SP behind the RP. " ?

Do you have IDP and SP functionality implemented both on ISVA, or is the SP functionality implemented using different SAML vendor/technology?

I'd recommend getting some ISVA Federation traces (com.tivoli.am.fim.*=ALL) on the IdP side, to see if you can identify where things go wrong.

Do you see it for all browsers?

There was a Chrome/Chromium browser change, that might some some problems with SP initiated SSO (https://www.ibm.com/support/pages/browser-changes-samesite-cookie-handling-and-ibm-security-access-manager)

If IDP & SP are both implemented on ISVA, are they both on the same appliance (= same Federation runtime)? As the Federated SSO functionality relies on session cookies, there is potential for getting this mixed up during the SSO flow.

https://www.ibm.com/docs/en/sva/10.0.2?topic=overview-known-limitations

The STS chain mapping created internally for Identity Provider and Service Provider will have identical ‘issuer’ and ‘applies to’ which can lead to unexpected behavior during runtime flow.

(traces will probably hold the truth :-) )

Thanks for your help. The SP is a vendor implementation (ComponentSpace) and that is what I meant by external windows server. Two things I am looking at:

1. I had to add the PartnerId to the idP URL from the SP because I need it on the idP login page. Could this cause an issue? I have %PartnerId% authentication macro enabled.
2. I have noticed that the AuthnRequest attribute AssertionConsumerServiceURL is not correct. It does not contain the junction. We have modified the partner idP definition with the proper information. The SAML 2.0 token is routed back properly but does not contain the attribute original ID moved into the InResponseTo attribute.

Thanks..