Shibboleth SP & Azure IDP CORS Issues

[Dan McLaughlin]

Update on my investigations so far...

The issue seems to be due to Angular Service Worker ngsw-worker.js.
It's caching the original request.  That's why a Shift+Refresh fixes
it.  We are working on testing adding ngsw-bypass=true query parameter
to the index.html to see if that fixes it.  The other option is to
enable a new Angular option in the ngsw-config.json called
"navigationRequestStrategy": "freshness", which will tell the service
worker to only use the cached files if the server can't be contacted.
A third approach would be to return a 404 when the service worker
tries to load the ngsw.json if there is no SP session, this will cause
the service worker to bail and let the browser handle the request.

--

Thanks,

Dan

On Thu, Feb 18, 2021 at 4:01 PM Dan McLaughlin
<dmclaughlin at tech-consortium.com> wrote:
>
> 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