Browserveranderingen op stapel: wat betekent dat voor inloggen met SURFconext?

De stappen die SURFconext, en evengoed SURF Research Access Management en eduID, nemen om een gebruiker in te laten loggen op een website verlopen bijna allemaal via de webbrowser van die gebruiker. Die begint in de browser een login op een website, gaat dan via diens eigen browser naar SURFconext en de instellings-loginpagina en weer terug naar de dienst. Op deze wijze wikkelen we 260 miljoen logins per jaar af. Hiervoor volgen we grotendeels het SAML-procotol, waarbij via standaard HTTP-acties zoals een redirect, een GET (pagina opvragen) en POST (gegevens opsturen) de SAML XML-berichten worden uitgewisseld tussen de verschillende partijen. Ook OpenID Connect is in essentie geheel HTTP-gebaseerd.

Hoe HTTP werkt staat eigenlijk al decennia vast sinds de uitvinding ervan bij CERN door Tim Berners-Lee in 1989. Sinds enkele jaren zijn de grote browserleveranciers - Google, Mozilla en Apple - hier wat aan beginnen te morrelen. Het gaat hen in de kern om cookies: een legitiem onderdeel van de HTTP-specificatie, maar zoals bekend veelvuldig gebruikt voor het tracken van gebruikers door advertentienetwerken. Het doel van de browserleveranciers is het beschermen van de privacy van de gebruiker - ze willen de mogelijkheden van trackingcookies en andere volgtechnieken inperken. Een cynischer blik is dat de leverancier van de grootste browser, Chrome, het tracken door anderen dan zijzelf lastiger wil maken. In deze blog zet ik op een rijtje welke wijzigingen er zijn geweest, welke eraan komen en wat de gevolgen kunnen zijn voor SURFconext en de aangesloten diensten en instellingen.

Al gebeurd: SameSite cookies

De eerste stap hebben we al meegemaakt. In SAML worden de berichten tussen twee partijen verstuurd middels een HTTP POST-actie van de ene url (bijvoorbeeld SURFconext) naar de andere URL (bijvoorbeeld de service provider). Bij zo'n actie worden door grote browsers sinds 2020 geen cookies meer meegestuurd, tenzij de cookies de vlag "SameSite=None" hebben. De ontvanger van zo'n SAML-bericht (de SP), moet dus diens cookies aanpassen met die vlag. Anders kan bijvoorbeeld de sessie van de gebruiker bij die dienst niet gevonden worden. Hierover hebben we destijds gecommuniceerd en inmiddels merken we hier nog slechts sporadisch de effecten van.

Next up: third party cookie deprecation

De volgende grote stap in het dwarsbomen van trackers is het afschaffen van "third party cookies". Een cookie kan gezet worden door een bepaalde site, en als je terugkomt op die site kan die de door hemzelf gezette cookies weer uitlezen. Dit heet first-party cookies en is de basis voor alle regulier cookiegebruik zoals loginsessies, winkelmandjes en wat dies meer zij. Je spreekt over third-party cookies als cookies gezet op bijvoorbeeld een domein van een adverteerder, uitgelezen worden door andere sites (die bijvoorbeeld een plaatje van het advertentienetwerk inladen). Hiermee kun je gebruikers tussen verschillende sites volgen. Google Chrome heeft aangekondigd dergelijke third-party cookies per begin 2025 niet meer te ondersteunen.

SURFconext maakt alleen gebruik van first-party cookies, dat wil zeggen, het zet zelf cookies die het ook weer uitleest als de gebruiker weer terugkomt. Voor ons is hier dus nog niet direct een risico. Het enige waar we risico in zien, zijn websites die (SURFconext-ontsloten) applicaties inladen in een zogeheten iframe binnen de pagina. Alhoewel iframes helemaal de bom waren bij de lancering van SURFconext in 2012, is het nu een marginale en zelfs onwenselijke techniek (omdat de gebruiker niet kan zien op welke site die zijn credentials invoert). We verwachten hier dus geen grote gevolgen van.

Daarna: bounce tracking en link decoration

Met het afschaffen van third-party cookies is het trackingprobleem nog niet opgelost. De advertentievrienden hebben namelijk nog meer gereedschappen in hun kist, waar de browser vendors daarna hun pijlen op willen richten. De eerste daarvan is het tegengaan van bounce tracking: de gebruiker via een redirect doorsturen naar een (tracking)site die de gebruiker zonder verdere interactie gelijk weer doorstuurt naar de eigenlijke site die die wilde bezoeken. Nu lijkt dat wel heel erg op wat wij ook doen: bij het inloggen worden gebruikers doorverwezen naar de SURFconext-proxy, die (soms zonder verdere interactie) de gebruiker direct weer doorstuurt naar de instellings-login. Hier zouden we dus wel iets van kunnen gaan merken.

Een mogelijke oplossing is dat we in het SAML-protocol afstappen van de "HTTP-Redirect"-methode van het initieren van een authenticatieverzoek en overstappen op de "HTTP-POST"-methode. Dit is standaard functionaliteit in SAML en OpenID Connect, en SURFconext en de mainstream library's die service providers gebruiken ondersteunen dit al. Vermoedelijk wordt het dan wel een transitie waarin configuratie aangepast moet worden bij de verschillende partijen, maar geen aardverschuiving.

Met link decoration doelt men op het toevoegen van allerlei persoonlijke ID's aan links die op een webpagina staan, om zo mensen die daarop klikken tussen de bron- en doelsite te kunnen volgen. De grote vraag is hierbij nog wat de precieze implementatie moet worden die dit soort ongewenste tracking-ID's niet meer gaat toestaan, en andere informatie die via URLs wordt overgedragen in SAML en OpenID Connect, wel. De precieze impact is hiermee dus nu nog lastig in te schatten.

Alhoewel beide ontwikkelingen zeker op de roadmap van browsers staan, zijn zowel de concrete implementatie als tijdspad nog ongewis. We houden de ontwikkelingen daarom scherp in de gaten.

De toekomst? FedCM

Zoals hierboven misschien al bleek, is het de browsermakers ook opgevallen dat het in de praktijk lastig is om ongewenst volgen tegen te gaan en tegelijk legitieme interactie tussen sites, zoals met Single Sign On (SSO) gebeurt, niet stuk te maken. Vanuit Chrome is hierom een nieuw voorstel gelanceerd: Federated Credential Management of FedCM. Een browser-API specifiek voor Single Sign On. Het implementeren van SSO doe je dan niet meer met "standaard" HTTP-interactie maar door het aanroepen van deze browser-api die de verschillende browsers dan moeten implementeren. Hiermee is SSO duidelijk apart te behandelen van ander gebruik van cross-site interacties waar je meer beperkingen op wilt leggen. Het voorstel is nog volop in ontwikkeling, en inmiddels is er een W3C-groep gevormd om de specificatie verder uit te werken. SURF neemt deel aan deze groep.

Lastig hierbij is dat de browsermakers geneigd zijn te denken vanuit hun eigen use cases zoals "Login met Google", en de behoeften van federaties met meerdere partijen wel eens uit het oog verliezen. Daarom zijn we samen met andere academische federaties in ons internationaal samenwerkingsverband (REFEDS) een werkgroep gestart die hierover de discussie met de browsermakers en in de W3C-werkgroep aangaat, om gezamenlijk onze usecases gewicht te geven in het ontwerp. Als FedCM er uiteindelijk komt, zal dit wel implementatie gaan vereisen bij in elk geval SURFconext en dienstaanbieders - waarbij er vermoedelijk ook nog een tijd is dat nog niet alle browsers deze nieuwe API ondersteunen.

Al met al is het dus nog niet exact duidelijk hoe de ontwikkelingen precies gaan werken en met welke snelheid dat zal gaan. Gelukkig zit SURF bovenop de ontwikkelingen en geeft ze waar mogelijk mede vorm. Voor aangesloten partijen is er nu nog geen actie nodig. Maar uiteraard is het altijd van belang om wendbaar ingericht te zijn, zodat wanneer er een wijziging zich aandient, je daar ook tijdig op kunt reageren. We houden jullie op de hoogte van de ontwikkelingen.

Vragen?

Het bovenstaande vat de ontwikkelingen in het browserlandschap samen voor zover wij nu denken dat die impact zullen hebben op federatieve authenticate. Heb je nog vragen of opmerkingen? Op support@surfconext.nl staan we altijd voor je klaar.