Issues with Chrome "prefetching" our IdP pages

[Feyaerts Vincent]

I might have found part of the solution. After some more digging, I saw that at least the SAMLRequest=... page on the IdP sets a Cache-Control: no store header. Which is of course perfect. My theory is that Chrome prefetches this page, refuses to store because of the header, and then needs to request it again immediately.

So what I do now is for these type of requests, which are unique anyway (so no caching issues can occur), I remove the header Cache-Control on the response.

Messy but it's better than what's happening now.

Regards
Vincent

From: users <users-bounces at shibboleth.net> On Behalf Of Feyaerts Vincent
Sent: woensdag 26 september 2018 11:13
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/20180926/8ecdd5f3/attachment.html>