Issues with Chrome "prefetching" our IdP pages

[Howes, Nick]

We have the exact same setup (ADFS, IdP, BIG-IP) and problem, so it seems like something ADFS is doing as an SP is exacerbating this, while I do think it's a Chrome problem. Users do sporadically see this as a Stale Request page when starting SP-initiated login, without any use of Back button (I can reproduce it myself).


In my investigations it seemed to be related to how Chrome sometimes treats a chain of redirects as a single entity and cache them as one, so I'd been trying to resolve this by making sure all the intermediate resources were uncacheable, but having read your messages I might have been going in the wrong direction.


Technically I suppose Chrome isn't doing anything wrong because it's a GET request which it's free to request whenever it feels like it, but it'd be good if there were a way to opt out through headers. I'll try various responses to the requests with the "Purpose: prefetch" header.


Nick

________________________________
From: users <users-bounces at shibboleth.net> on behalf of Feyaerts Vincent <vincent.feyaerts at uantwerpen.be>
Sent: 26 September 2018 10:12:41
To: users at shibboleth.net
Subject: Issues with Chrome "prefetching" our IdP pages


Hi,



We have a set-up consisting of ADFS+Shibboleth 3 IdP. ADFS is the slave SP. Both are load balanced behind a Big-IP F5 LTM. Our problem is not really related to this set-up. I think it might occur in any normal IdP deployment.



The Shibboleth IdP back-end logs are full of messages like:



org.opensaml.messaging.handler.MessageHandlerException: Rejecting replayed message ID 'id-f7e02f5c-843f-4d3d-88af-168b8a79653e' from issuer http://url/adfs/services/trust

        at org.opensaml.saml.common.binding.security.impl.MessageReplaySecurityHandler.doInvoke(MessageReplaySecurityHandler.java:157)



I checked our logs of the load balancer, the client does indeed request the URL with the SAMLRequest referencing that ID twice. Now, it appears one of those requests has a header “Purpose prefetch”. This is a Google Chrome header. Now, I have no idea why it would prefetch these pages but it does.



Technically speaking this might be a Chrome problem, but it interferes with a normal Shibboleth IdP from working, and I hope somebody else has found a way to fix this on the IdP, because I can’t change Chrome.



I tried sending a 403 as a response to the Prefetch request, but then Chrome just stops and won’t ask again.



Regards

Vincent Feyaerts




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20181015/d4db7260/attachment.html>