Shibboleth SP & Azure IDP CORS Issues

[Dan McLaughlin]

Sorry for the long post, but it's complicated.

We are currently running into CORS issues authenticating with Azure.
I'm not certain when this started happening, but I'm suspecting the
Chrome 84 release changes related to SameSite settings have something
to do with the failures.  We only seem so see this if someone has left
their browser open overnight and the SP and IDP session timeouts have
expired.  The user refreshes the screen, the SP redirects them to the
URL seen in the error message below, but instead of taking them to the
MS login page for Azure they get a Chrome error page that says

"This site can’t be reached.
The webpage at https://myhost.mydomain.com/secure/MyApp/app/home might
be temporarily down or it may have moved permanently to a new web
address.

ERR_FAILED."

If you look in the Developer Console you will see a CORS error similar
to the one below...keep reading below.

Access to fetch at
'https://login.microsoftonline.com/<Azure-Subscription-ID>/saml2?SAMLRequest=hVLJbsIwEP2VyPfEsRMIsQgSLYcidUGF9tBL5TgDWHJs6GHJNBGHJjnmhgBNjmnHgvbnYWnjrAEL22xqI4DirSeSucRI3CyhZQBCXW86tLwZNUHLwLTjlDojki%2BKCdPXcWuxb8GvyzVnB3e1mRfQgHFJQqr7GB56RxIcEgAyThNemQrve6FGHJKMNBVGHBNjhnmvvJnbvbNmnBgvBnnrXMi3E8UmkZ52qcxSVrZKygkJmsR5znDR2CcRItFxV5lMMEJpMxNCxvthNI8yIrRrwu2QQkYz0MsYOl7f3aUBGechanPGbFJs3EaCxY%2BUCi1UcPZ9o22u7%2BLq0%2BgVBcbDar%2BBTzHjweI%2FYAMpsODsVR2P84xt%2B08vMCZPZfBNbvhjmNBHGBnmnbnmcrJzR6i2aG%2BNezj302xVhhM5OK78%2FZvYO&RelayState=cookie%3A1234567_b30b&SigAlg=http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256&Signature=wyZOL6I%2BoVGHJNbgfVBNHjmnBHgVbnMnBgfvbnlTP0kvfvpxBvTmVuY9%2B7Ebp8GVBNMNHgbNJmnhGVbNjMnbgvbnm3A9sM%2FKuiNYtCmIBJKMnhbgvbnJKMNHGvbnmNBHGVatEyUmfMrONNnpjV8INVqEk%2BdouzlDsz6xyJr4%2BHTLNGae6Ur%2FpWPb9oDRVXDxcxWb%2FQh5lUavLMh6Z6imoJW1Et45bVEo2plqu43GMJHGBnjkMNhgbnhJk<mJhGFdcVgHjNbgfvbhQijFbBUD1XXtlXl4TNDexN5iBF8oBz6CYd1tTerlFBdzfTsH6BhOelnNny5rPnxnYL9AHyWdrKn06qMMLpnEdwdBhmDy1ndeZPH0DNZcEAvFWpumebtQW3ECIAkwNQhpvdBHGJKMnhgvbnJKGHMnjhgVBnhJkHJmnHgvbNmKGVHkMJhgfGhJkJHgf'
(redirected from
'https://myhost.mydomain.com/secure/MyApp/ngsw.json?ngsw-cache-bust=0.15771129608693557')
from origin 'https://myhost.mydomain.com/' has been blocked by CORS
policy: No 'Access-Control-Allow-Origin' header is present on the
requested resource. If an opaque response serves your needs, set the
request's mode to 'no-cors' to fetch the resource with CORS disabled.

You can refresh the screen all day long and you will keep getting the
same error message and CORS error.  However, if you do Shift+Refresh
(no-cache refresh) then it will break the cycle and you will be sent
to https://login.microsoftonline.com to authenticate.   Here's where
it get's weird...I've also seen if you just let the browser sit for
about 30 seconds after getting the error, Chrome will automagically
start making more requests for files related to the initial request,
like images, javascript, etc...I'm assuming it's doing this based on
cached information it has about the context being requested, and each
time the SP redirects back to Azure and each time the response is the
same CORS error above. After 3 - 4 requests for other assets (it seems
to vary), Chrome then makes another request for the Initial requested
page and you finally get to the login page and no CORS error.

Based on the error message above it would seem that if I could figure
out a way to configure Azure to set the
Access-Control-Allow-Origin=https://myhost.mydomain.com then the CORS
error would go away, but to-date I haven't figured out a way to do
that and I've had a ticket open with MS Azure support for 2 weeks now
and they haven't provided any guidance either.

My second theory that I'm still investigating is that this has nothing
to do with the SameSite changes and everything to do with the Referrer
Policy change made in Chrome 85 that changes the default Policy to
strict-origin-when-cross-origin.  One thing I notice is that all the
failed requests are from a Service Worker with the Referrer Policy set
to no-referrer-when-downgrade and the Referrer and Origin set and the
HTTP response is CORS Error, and the last request that finally works
the Referrer Policy is set to strict-origin-when-cross-origin and no
Origin or Referrer Header set.

My third theory I'm investigating is that the Service Worker is
somehow getting in the middle of things and causing issues. All of the
requests that fail have the remote address as
localhost/0:0:0:0:0:0:0:1 (assuming this is the Service Worker
address), and the final request that works is to 20.190.154.139 (Azure
IDP).

Anyways, any pointers would be greatly appreciated.

--

Thanks,

Dan