Instellingen moeten controle houden over het beveiligingsniveau van de aangesloten diensten. Zij bepalen de sessieduur per dienst. Hierbij moet een balans worden gevonden tussen gebruikersgemak (Single sign-on) en veiligheid. Op deze pagina staat technische achtergrondinformatie over sessies van SURFconext, Identity systemen van de instelling (IdP) en die van de aangesloten diensten (SP). Daarbij wordt antwoord gegeven op vragen zoals "Wat zijn sessies en hoelang duurt een sessie?", "Hoe werken sessies in de SURFconext authenticatie infrastructuur?" en "Wanneer en waarom moet ik opnieuw inloggen?".
De achtergrond
Het HTTP protocol waar het Web op is gebouwd is 'stateless'. Dat betekent dat ieder 'request' (is een verzoek in de vorm van een URL) dat een webbrowser naar een webserver stuurt een nieuw verzoek is. Een request heeft geen notie van een voorgaand request en staat volledig op zichzelf. Om 'state' bij te houden worden 'cookies' gebruikt. Een cookie is een klein stukje informatie dat door de webbrowser wordt meegestuurd bij ieder request. De webserver kan in het cookie gegevens bijhouden en daarin allerlei informatie opnemen, zoals de naam van de gebruiker etc. Het is gebruikelijker dat de webserver iedere webbrowser een unieke code geeft, die staat voor een sessie. Dit is een voorbeeld van een cookie, met een unieke sessie code:
cookie : session=5cfccca1129cbaaf262a3d7c334df8b0
Op basis van de sessie code wordt door de webserver in een database gekeken welke gebruiker hier bij hoort. Een naam, maar ook allerlei andere informatie die door de webserver gewenst is en ooit eerder door de gebruiker is opgegeven.
Over sessies, sessiemanagement en sessieduur
Een cookie met een sessie wordt over het algemeen aangemaakt bij het eerste bezoek van de webbrowser bij de webserver, zodat in vervolg bezoeken de browser wordt herkend aan de hand van de inhoud van het cookie. Zowel de webbrowser en de webserver hebben invloed op deze sessie. De webbrowser zal in het meest gebruikelijke scenario zich schikken naar de wensen die de webserver heeft geuit, maar daar kan niet vanuit gegaan worden.
Merk op dat in dit document over HTTP sessies wordt gesproken, er bestaan ook sessies op andere niveaus, zoals de SAML sessie voor uitwisseling van de authenticatie gegevens, de TLS sessie voor de encryptie van gegevens of de TCP sessie voor het transport van de gegevens.
De webserver bepaalt dus om te beginnen de duur van de sessie. Een webserver kan een cookie laten verlopen na een bepaalde periode door aan het cookie de levensduur van het cookie mee te geven, de browser zal na deze levensduur het cookie verwijderen en niet meer meesturen, waardoor de webserver de browser niet meer herkent. Maar de webserver kan zich niet afhankelijk van de browser opstellen. Wat als de browser het cookie niet verwijdert? Dan zou hij in theorie oneindig lang met hetzelfde cookie requests mogen doen. Daarom zal de webserver zelf ook de levensduur en activiteit bijhouden. Hierdoor kan het voorkomen dat de webbrowser een cookie meestuurt naar de server, maar dat de server aangeeft dat het cookie niet meer geldig is.
De webbrowser heeft ook invloed op de sessie. De gebruiker kan een cookie weggooien, waardoor hij zijn eigen sessie beëindigt. Een cookie kan ook bewerkt worden. Dat feit legt meteen het gevaar van het gebruik van cookies voor sessiemanagement bloot. Niets staat iemand in de weg om een sessie van iemand anders te kopiëren en in zijn eigen webbrowser te gebruiken, waarmee hij de identiteit van die persoon overneemt. Dit heet 'session hijacking' en is nog steeds één van de grootste beveiliging risico's van webapplicaties.
De twee belangrijkste maatregelen om session hijacking te beperken zijn:
1. Ervoor zorgen dat een sessie code niet zichtbaar is. Versturen van een cookie moet daarom altijd over HTTPS gaan, zodat de sessie code onderweg versleuteld is.
2. De levensduur van een cookie beperken, waardoor de houdbaarheid van de sessie beperkt wordt.
Meer achtergrond informatie over de gevaren en beveiliging van sessies is te vinden op de owasp website, waar beveiliging van software wordt besproken. Dit is een link naar specifieke sessiemanagement informatie: https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management
Factoren die de sessieduur beïnvloeden
Zoals hierboven beschreven is het beperken van de sessieduur een beveiligingsmaatregel. Er zijn meerdere factoren die een rol spelen bij het bepalen van de sessieduur:
1. Allereerst dus het security niveau wat bereikt moet worden. Banken kiezen er bijvoorbeeld voor om sessies van gebruikers die inloggen om banktransacties te doen al na 5 minuten inactiviteit te verwijderen.
2. Het is niet voor iedere applicatie noodzakelijk een korte sessieduur van een paar minuten te handhaven. Het is bijvoorbeeld afhankelijk van het soort data die bewerkt wordt en de applicatie waarvan gebruikt gemaakt wordt. Het ene type data of soort applicatie wordt als gevoeliger ervaren dan het andere type.
3. Ook speelt de gebruikservaring een rol bij het bepalen van de sessieduur. Gebruikers zijn gewend om bij sommige applicatie ingelogd te blijven, zodat de applicatie snel kan worden gestart, zonder opnieuw in te loggen, zoals bijvoorbeeld bij Gmail van Google. Overigens kan de applicatie wel beslissen om na een bepaalde periode de sessiecode te veranderen, zodat niet de hele periode dezelfde code wordt gebruikt.
4. De webbrowser heeft ook invloed op de sessieduur, wat nog niet hierboven is besproken. Naast een duur in tijd, kan ook de geldigheid van een cookie gekoppeld worden aan het openen en afsluiten van de webbrowser. Dit worden ook wel 'session cookies' genoemd. Na afsluiten van de webbrowser, worden deze cookies verwijderd, zodat na opnieuw opstarten van de browser de gebruiker niet herkend wordt.
5. Als laatste moet bij het bepalen van de sessieduur ook het device van de gebruiker in acht worden genomen. Als iemand gebruikt maakt van een openbare computer, dan is het zinvol om de sessie te laten beëindigen na afsluiten van de webbrowser, zodat de volgende gebruiker met een schone lei begint en niet verder kan gaan waar de vorige gebruiker was gebleven. Met een mobiel device, waar tegenwoordig met een vingerscanner de gebruiker zijn device kan ontgrendelen, kun je er misschien wel vanuit gaan dat dit altijd dezelfde persoon is.
Het is belangrijk goede afwegingen te maken bij het bepalen van de sessieduur op alle genoemde gebieden.
Sessies in de SURFconext authenticatie infrastructuur
In de SURFconext authenticatie infrastructuur is er niet sprake van één sessie, maar moet er rekening gehouden worden met drie verschillende sessies, die te maken hebben met de manier van inloggen via SURFconext met het account van de instelling.
In het onderstaande scenario wordt met een schone lei begonnen. Dat betekent dat er vanuit gegaan wordt dat de gebruiker nog niet ingelogd is geweest bij een aangesloten dienst, zodat Single Sign On nog niet werkt. De gebruiker zou namelijk al een SURFconext en IdP sessie kunnen hebben, als hij al een aangesloten dienst had bezocht.
I. Allereerst gaat een gebruiker (met zijn webbrowser) naar de dienst (SP). Op dat moment zal de webserver van de dienst de gebruiker doorsturen naar SURFconext.
II. Aangekomen op SURFconext zal SURFconext de gebruiker doorsturen, eventueel via de WAYF, naar de login pagina van de instelling (IdP).
III. Op de IdP, zal de gebruiker inloggen en na een succesvolle login wordt de sessie gestart. Via SURFconext wordt de gebruiker teruggestuurd naar de dienst. Op SURFconext en de dienst wordt op die contact momenten ook een sessie gestart.
De webbrowser heeft dus contact gehad met drie webservers, de SP, SURFconext en de IdP, die alle drie een eigen sessie zijn gestart, onafhankelijk van elkaar.
Belangrijk om nu te constateren is dat NA deze inlog de gebruiker NIET meer bij SURFconext of de IdP komt. Zolang de sessie op de SP actief is, zal de gebruiker van de SP gebruik kunnen maken zonder tussenkomst van SURFconext en de IdP.
Sessieduur van op SURFconext aangesloten diensten
Zoals blijkt uit het voorgaande heeft de dienst de sessieduur zelf in de hand. Dus op basis van de factoren die de sessieduur bepalen kan een dienst een eigen inschatting maken van het beveiligingsniveau wat bereikt moet worden. Zoals later in dit artikel wordt toegelicht is uitloggen van de infrastructuur erg complex. Daarom is de aanname van SURFconext dat een SP altijd van sessie cookies gebruik maakt. Zodat de gebruiker uitlogt van een dienst als de browser afgesloten wordt.
Afhankelijk van de gevoeligheid van de data kan de dienst beslissen om na een paar minuten of na een paar uur de sessie te stoppen.
Invloed van SURFconext en de IdP op een dienst
Zolang de sessie op een SP actief blijft, is de volledige controle bij de SP. Op het moment dat deze SP sessie afloopt of de gebruiker uitlogt van de SP gaan SURFconext en de IdP weer een rol spelen. Als de gebruiker zich namelijk opnieuw meldt bij de dienst, dan zal de dienst de gebruiker doorsturen naar SURFconext. Op dat moment kan SURFconext nog wel de gebruiker herkennen met de sessie die door SURFconext zelf is gestart, zodat deze direct naar de IdP wordt doorgestuurd, waar de gebruiker ook herkend kan worden met de sessie die door de IdP was gestart. Dan wordt de gebruiker automatisch teruggestuurd naar de SP en is hij ingelogd, zonder opnieuw zijn gebruikersnaam en wachtwoord achter te laten op de IdP.
Het is belangrijk de invloed van SURFconext te begrijpen: SURFconext zal niet beoordelen of een gebruiker wel of niet ingelogd is geweest op een IdP. De sessie van SURFconext wordt alleen gebruikt om de WAYF te omzeilen. De eerste keer dat een gebruiker bij SURFconext komt, dan wordt een WAYF getoond, zodat hij zijn eigen instellings IdP kan kiezen. De volgende keer zal de gebruiker naar dezelfde IdP gestuurd worden door SURFconext, zonder de WAYF te gebruiken.
SURFconext gebruikt voor deze sessie een sessie cookie en die wordt opgeheven op het moment dat de gebruiker zijn webbrowser afsluit. Deze sessie wordt door SURFconext 30 minuten bewaard, waarna de gebruiker opnieuw zijn instelling uit de WAYF moet kiezen. Binnenkort zal deze sessieduur waarschijnlijk opgehoogd worden (naar bijvoorbeeld 8 uur).
De invloed van de IdP op de sessieduur is groter dan die van SURFconext, de IdP bepaalt namelijk wel de sessieduur van de authenticatie van de gebruiker. Als de sessie bij de IdP nog actief is, dan wordt de gebruiker automatisch ingelogd op de IdP en dus ook op de SP. IdP's zijn vaak ingesteld op 8 uur (een werkdag).
Merk op dat het dus geen zin heeft op de SP een kortere sessie te gebruiken dan op de IdP. Als de SP sessie namelijk afloopt voordat de IdP sessie verloopt, dan wordt bij een volgend bezoek aan de SP de gebruiker alsnog automatisch ingelogd. Dit levert geen extra beveiliging, maar wel extra (onnodige) bezoeken aan de IdP en SURFconext. De IdP bepaalt dus eigenlijk de minimale sessieduur en daarmee de mate van beveiliging.
Naast het gebruik van sessie cookies (beschreven in de vorige paragraaf) is het voor een SP ook belangrijk om de sessieduur van de IdP als ondergrens in te stellen. De bovengrens kan uiteraard wel door de SP bepaald worden.
SAML kan de SP helpen bij het instellen van de sessieduur
Om de sessie ondergrens te bepalen kan de SP proberen deze informatie uit de SAML response te halen. In de SAML response staat namelijk een AuthnStatement die deze informatie kan bevatten, bijvoorbeeld:
<saml:AuthnStatement AuthnInstant="2014-07-17T01:01:48Z" SessionNotOnOrAfter="2014-07-17T09:01:48Z" SessionIndex="_be9967abd904ddcae3c0eb4189adbe3f71e327cf93">
Hier staat dat de authenticatie door de IdP afgegeven is op tijdstip 'AuthnInstant' en geldig is tot het tijdstip 'SessionNotOnOrAfter' (een sessieduur van 8 uur in dit geval) en de code van deze sessie is 'SessionIndex'. Merk op dat deze informatie niet altijd beschikbaar hoeft te zijn. Dus de SP moet ook zelf een alternatief kunnen bieden.
Als de SP toch een kortere sessieduur vereist dan de IdP aangeeft, dan kan er een parameter meegegeven worden in het SAML request om bij de IdP een login te forceren ongeacht of de gebruiker al een IdP sessie heeft. Dit is de parameter ‘ForceAuthn’. SURFconext stuurt deze door naar de IdP, waarna de IdP de gebruiker opnieuw om login informatie dient te vragen. Hiermee wordt als het ware Single Sign On uitgezet. Om ‘ForceAuthn’ te garanderen moet er signing en verificatie plaatsvinden tussen de zender en ontvanger, in dit geval tussen de SP en SURFconext en SURFconext en de IdP. Dit is niet standaard beschikbaar.
Meer over Authentication requests en responses is te lezen op de SURFconext wiki: https://wiki.surfnet.nl/display/surfconextdev/Authentication+using+SAML
Wat is SSO nu precies?
Met Single Sign On wordt bedoelt dat je met één keer inloggen tot meerdere diensten toegang krijgt. Uit het bovenstaande verhaal blijkt dat de duur van Single Sign On hetzelfde is als de duur van de sessie op de IdP. Zolang de sessie op de IdP niet verlopen is, kan een gebruiker blijven inloggen op alle diensten die via SURFconext aan de IdP gekoppeld zijn, zonder daarbij steeds opnieuw in te loggen op de IdP. De IdP bepaalt dus de SSO.
En waarom kan uitloggen dan niet?
Het zal nu ook duidelijk zijn dat uitloggen op een SP geen optie is, zolang de sessie op de IdP nog actief is. De gebruiker zal dan door Single Sign On, bij terugkeer naar de SP gewoon weer inloggen. Alleen uitloggen op de SP en de IdP, zorgt ervoor dat de gebruiker niet automatisch opnieuw op de SP inlogt.
Alleen is dat niet zo eenvoudig als het lijkt, want ben je wel uitgelogd als je van één SP en de IdP uitlogt? Er kan sprake zijn van meerdere diensten, die ook allemaal via dezelfde IdP ingelogd waren. De sessies van die andere SP's kunnen nog actief zijn. Moet er dan ook niet op die SP's uitgelogd worden? Er zijn in de SAML standaard wel mechanismen gedefinieerd om dit te realiseren, maar in de praktijk blijkt dit zeer lastig te realiseren en wordt dit weinig gedaan.
Wanneer en waarom moet ik dan opnieuw inloggen?
Dit zijn de consequenties als er één van de drie verschillende sessies verloopt:
1. Als alleen de IdP sessie verloopt, dan kan er gewoon doorgewerkt worden op de SP. Pas bij verlopen van de sessie op de SP of bij een nieuwe SP wordt de browser via SURFconext doorgestuurd naar de IdP en wordt er op de IdP weer om inloggen gevraagd.
2. Als alleen de SURFconext sessie verloopt, dan kan er ook gewoon doorgewerkt worden op de SP. Bij het verlopen van de sessie op de SP of bij het openen van een nieuwe SP wordt er door SURFconext opnieuw een WAYF getoond om de instelling te kiezen. Na kiezen van de instelling wordt er dan automatisch ingelogd op de IdP.
3. Als alleen de SP sessie verloopt, dan kan bij terugkeer naar de SP of bij het openen van een nieuwe SP alsnog automatisch ingelogd worden via de bestaande sessies van SURFconext en de IdP, dit noemen we Single Sign On.
Dus eigenlijk moet er alleen opnieuw ingelogd worden als de sessie op de IdP verlopen is. Als de sessie op SURFconext verlopen is, dan wordt er opnieuw een WAYF getoond om een instelling te kiezen.
Advies voor de SP Sessieduur
Voor op SURFconext aangesloten diensten wordt geadviseerd om sessie cookies te gebruiken, zodat in ieder geval bij afsluiten van de browser alle sessies tegelijk worden gestopt. Verder adviseren wij dat aangesloten SP's zich houden aan de sessieduur van de IdP, zodat de IdP de controle houdt over het beveiligingsniveau van de aangesloten diensten.
Samenvattend
In dit artikel is sessiemanagement uitgelegd en is er inzicht gegeven in de factoren die de sessieduur beïnvloeden. Daarnaast is het gebruik van sessies in de SURFconext authenticatie infrastructuur uitgelegd en zijn de rollen van de SP, IdP en SURFconext onder de loep genomen.
Er zijn een aantal veel gestelde vragen beantwoord en er is een advies gegeven voor het bepalen van de sessieduur voor een SP.
Uit het artikel is duidelijk geworden dat de IdP de controle heeft over de sessieduur en Single Sign On. De SP kan de IdP informatie overnemen en eventueel een nieuwe login forceren. De rol van SURFconext blijkt vrij beperkt te zijn.