Edge Chromium does not http post SAML data to IEMode user access URL

5
votes

Our website is requiring IEMode in Edge Chromium and our user is using SSO. When they log in from their SSO log-in URL, their Edge Chromium browser opens up our website (user access URL) in IEMode as expected but they are getting an error in authentication.

From our user's SSO log-in, the request type our website is receiving is GET so we are getting the error “Failed to receive SAML response by HTTP post”, we are expecting an http posted SAML data. Developer Tools does not work on IEMode so tracing stops right before IEMode page loads.

As instructed by https://docs.microsoft.com/en-us/deployedge/edge-ie-mode-sitelist#configure-neutral-sites, we have tried including the SSO login domain to the EMIE sites list with open-in as None but we still get the same result. If we change the open-in as IE11 (same as our website's), it works. This just is not an option our user wants to use (setting login domain to open in IE11) as our user has other apps that use SSO and require to be not in IEmode.

Is there a header or IIS setting we can change, or another Edge Chromium browser setting or even registry setting we can modify, to work around this Edge Chromium-to-IEMode SSO issue?

1
single-sign-oninternet-explorer-11microsoft-edgesaml
If dev tools doesn't work, you can use Fiddler to capture the HTTP traffic to see if it can root the issue. I think it will be helpful to identify why you're receiving an HTTP Get. Besides, I also find a similar thread and you can refer to the answer. - Yu Zhou
Thanks @YuZhou. I tried not using aspx from the answer you linked to but I still get the same issue. I traced the following traffic on Fiddler -- With SSO log-in domain using open-in IE11 like our site: POST https://oursite.com/SSO HTTP/1.1 Referer: https://ssologin.com Content-Type: application/x-www-form-urlencoded Content-Length: 4763 Cache-Control: no-cache SAMLResponse=*** With SSO log-in domain using open-in None, I get this: GET https://oursite.com/SSO HTTP/1.1 I get same headers on both: Accept, Accept-Language, User-Agent, Accept-Encoding, Host, Connection and Cookie. - Glenda Suarez
The process switch from msedge to iexplore may be causing it to drop the POST data and reverting to GET. It is doing two CONNECT requests in both processes. - Glenda Suarez
It's complex to troubleshoot as there's limited information and we can't reproduce the issue with the above information. All I can provide are some suggestions. If you like, you can open an assisted support according to this site. - Yu Zhou
We see this on some machines in our organization that only differ in minor wsus patch levels, first report in the last week. This might be a regression in Edge or increase in volume soon : ( - Stephan B

1 Answers

0
votes

We did not find the root cause, but we prepared a fix that might be useful for some.

When redirecting from SAML IdP to the Application and simultaneously switching from Edge to IE the request that should be POST becomes a GET - most Applications do not accept this. If this is your Application you can modify it to process the GET as if it where a POST, or maybe better make it work in Edge ; )

We set up another SAML IdP and migrated all legacy applications that must be opened in IE to this service and added its URL to the IE site list. Now there is no switch between Edge and IE mode and SSO works.