Hoe relevant is uitloggen vandaag nog?

Wat was het probleem ook alweer?

De uitdaging bij federatief uitloggen is dat een eenvoudige, lokale uitlogknop op een applicatie (service provider of SP) op zichzelf niet erg effectief is. Wanneer de lokale sessie van de applicatie wordt beëindigd, en de gebruiker op "login" op die applicatie drukt, wordt hij/zij weer direct ingelogd vanwege de actieve single-sign-on-sessie op zijn/haar identity provider (IdP). Het is belangrijk om te begrijpen dat al het single-sign-on-gedrag in onze federatie wordt geïmplementeerd door de identity provider. Elk login-verzoek aan een service provider wordt door SURFconext naar de IdP van de gebruiker gestuurd en de IdP van de gebruiker bepaalt of de gebruiker een actieve sessie heeft en zo ja, stuurt de gebruiker direct terug via SURFconext naar de dienst.

Wanneer applicatieontwikkelaars of gebruikers vragen om een log-out-knop, moet de eerste vraag zijn wat ze daarmee eigenlijk bedoelen. Stel dat de gebruiker via SURFconext inlogt op Blackboard en later op  haar e-mail. Dan klikt zij op log out in de Blackboard-applicatie. Welke bedoeling heeft deze gebruiker, wat wil ze bereiken? Gewoon uitgelogd worden in Blackboard, en verder werken aan haar e-mail? Of uitgelogd worden in alle applicaties waarop ze in deze sessie is ingelogd? Is het logisch om het uitloggen van de e-mail te starten via een knop in de Blackboard-applicatie? Waarschijnlijk verwachten verschillende gebruikers verschillende dingen. De meeste gebruikers zullen verwachten dat ze alleen worden uitgelogd uit de applicatie waarin ze de knop hebben gebruikt (we noemen dat vanaf nu ‘gedeeltelijke logout’). Anderen die wel op de hoogte zijn van het bestaan van single log out zouden kunnen verwachten dat ze ook worden uitgelogd uit hun e-mail. Dus elk van de twee strategieën kan voor een bepaalde groep gebruikers  in strijd zijn met het principe van de minste verrassing.

Verschillende aanpakken

Desalniettemin zijn er enkele pogingen gedaan. In theorie maakt het SAML 2.0 protocol een volledige single log out (SLO) mogelijk van alle applicaties waarop de gebruiker in deze sessie is ingelogd. Echter, dit protocol is ervan afhankelijk dat alle betrokken dienstverleners het correct implementeren en beschikbaar zijn op het moment van uitloggen. Bij het starten van een SLO wordt de gebruiker heen en weer gestuurd tussen zijn IdP en alle dienstverleners, zodat elke entiteit zijn eigen logout kan uitvoeren en de controle kan doorgeven aan de volgende. Als een van de dienstverleners om welke reden dan ook faalt, krijgt de gebruiker een HTTP-fout en stopt het uitlogproces. Er bestaat een variant die dit probeert te parallelliseren door gebruik te maken van iFrames, maar de meeste webapplicaties sturen tegenwoordig HTTP-headers die het gebruik van iFrames blokkeren. Wij vinden deze aanpak te fragiel om betrouwbaar te zijn. Zelfs als je deze kwetsbaarheid zou accepteren, blijft de vraag op welke plek de gebruiker deze single log out zou initiëren - binnen een van de service providers (doet waarschijnlijk niet wat ze verwachten, zie hierboven)? Of op een centraal portaal? Zullen gebruikers zo'n plek vinden en gebruiken?

Een andere mogelijke aanpak is dat SURFconext een gedeeltelijke log out-functionaliteit implementeert, waarbij de SLO-protocol-voorzieningen van SAML worden hergebruikt. Service provider B kan de sessie van de gebruiker beëindigen en het SLO-endpoint van SURFconext aanroepen, en SURFconext kan het SLO-endpoint van de IdP aanroepen. Dit beëindigt de sessie bij de IdP. Andere ingelogde service providers behouden hun actieve lokale sessies, maar wanneer ze weer toegang vragen tot B, of in feite elke andere SP die nog geen lokale sessie voor de gebruiker heeft, wordt de gebruiker door zijn IdP gevraagd naar zijn of haar credentials. Dit zou in de praktijk kunnen werken. Het is echter nog steeds in strijd met het element van de minste verrassing voor die gebruikers die zouden verwachten dat ze overal afgemeld zouden worden.

Sommige dienstverleners hebben ook geëxperimenteerd met het instellen van de ForceAuthn-vlag in AuthnRequests die door hun SP worden verstuurd om single sign-on altijd uit te schakelen voor hun SP. Dit gooit echter niet alleen de voordelen van SSO uit het raam, het is ook niet waterdicht, omdat het gemakkelijk is om AuthnRequest-instellingen te omzeilen. Niet alleen omdat AuthnRequests voor de IdP's in SURFconext niet worden ondertekend, maar ook omdat veel SP's Unsolicited SSO ondersteunen - en dat kun je in populaire implementaties niet uitschakelen -, waarmee je überhaupt zonder een AuthnRequest kunt inloggen op de SP.

Het algemene advies dat wij momenteel hanteren is dat de gebruiker alle browservensters moet sluiten. Naast het feit dat het een vrij botte maatregel is, verliest het ook snel zijn effectiviteit omdat browsers tegenwoordig de neiging hebben om sessiecookies actief te houden, zelfs tussen verschillende browsersessies:het sluiten van die browsers heeft daarmee geen effect op de inlogsessie van de gebruiker.

Is het probleem eigenlijk wel een probleem?

Laten we nog eens terugkomen op de wens voor een uitlogknop. Mensen die een login-knop implementeren, vragen daar vaak reflexmatig om. Maar in de moderne wereld lijkt het eigenlijk een veel minder relevante functie dan het ooit was. Om te beginnen moeten we eerst eens kijken waarom mensen zouden willen uitloggen. Je wilt uitloggen om te voorkomen dat iemand anders je sessie gebruikt. Dit was relevant toen je een publieke PC in de universiteitsbibliotheek gebruikte. Of wanneer je snel de computer van een vriend gebruikt om je rooster voor morgen op te zoeken.

Maar laten we eerlijk zijn, hoe relevant zijn deze scenario's in 2020? Als je onderweg je rooster wilt opzoeken of je e-mail wilt lezen: iedereen heeft tegenwoordig een apparaat op zak dat hij of zij zelf bezit en niet deelt (de apps op dit apparaat zijn meestal continu ingelogd). Het aantal gedeelde werkstations op campussen neemt snel af, en voor degene die blijven, mag je hopen dat ze zichzelf na elk gebruik opnieuw instellen. Zo niet, dan zit het probleem niet in single sign-on maar in deze werkstations. En mocht je toch in een situatie terechtkomen waarin je de computer van iemand anders zou willen gebruiken: kennis over het gebruik van privé-browsingsessies wordt inmiddels mainstream, en is een effectieve oplossing voor dit geval.

Het is dus de vraag hoeveel we nog moeten investeren in het bedenken van min of meer complexe uitlog-scenario's. Ik geloof echter dat er nog steeds iets kan worden gedaan.

Wat kunnen we wel doen?

Alle hierboven genoemde oplossingsrichtingen benaderen het probleem vanaf het moment dat de gebruiker klaar is met werken. Ik geloof echter dat we de levenscyclus van de inlogsessie veel effectiever kunnen beheersen als we deze vanaf het begin bezien. Wanneer de gebruiker voor het eerst inlogt, vragen we hem of haar op het inlogscherm van de identity provider of hij of zij via single sign-on wil inloggen, of dit hun eigen vertrouwde apparaat is. Als dat het geval is, wordt er een single-sign-on-sessie gestart. Als ze deze optie niet selecteren, bijvoorbeeld wanneer ze zich op een minder vertrouwd apparaat bevinden, zal het inloggen normaal werken, maar elke volgende serviceprovider waarbij ze willen inloggen, zal gewoon weer het inlogscherm presenteren. Dit voorkomt de problemen die vaak geassocieerd worden met single sign-on zoals hierboven gepresenteerd, het is niet moeilijk te implementeren en het leuke is dat het alleen wijzigingen aan de Identity Provider vereist - dat wil zeggen, elke IdP kan voor zichzelf beslissen om dit aan te bieden aan hun gebruikers. Sterker nog, enkele hebben dat al gedaan.

Het idee kan verder worden verbeterd als de IdP rekening houdt met contextuele factoren van de gebruiker bij het al dan niet inschakelen van single sign-on voor de gebruiker. Zit hij bijvoorbeeld binnen het campusnetwerk of komt hij met een eerder (voor hen) ongeziene browser? Dit zou het nog gebruiksvriendelijker maken, maar de implementatie ook compliceren. Bovenstaande oplossing zou daarom een goed startpunt kunnen zijn.

Wat denk jij, is dit iets wat ons huidige single-log-out-vraagstuk zou kunnen verlichten?