Keyrollover bij SURFconext

Begin 2019 hebben we de basis van de federatie vervangen: het sleutelmateriaal van SURFconext. Een zogeheten keyrollover. Een groot project waarvoor alle dienstaanbieders (of SP’s) in actie moesten komen. Waarom deden we dit, hoe deden we dat en wat levert het op?

Waarom?

SURFconext maakt gebruik van het SAML 2.0-protocol. De login-informatie wordt in een bericht via de browser van de gebruiker verstuurd naar de dienstaanbieder. Om te voorkomen dat die gebruiker de informatie onderweg kan vervalsen (en bijvoorbeeld Jan zou kunnen claimen dat hij Klaas is) zijn deze XML-berichten door SURFconext ondertekend met een sleutel, die door de SP vertrouwd wordt. De dienstaanbieder kan zo controleren of de login-informatie echt van SURFconext afkomstig is (rode pijl in afbeelding 1).

Schema weergave van succesvol inloggen
Afbeelding 1, ook te vinden op https://metadata.surfconext.nl/

SURFconext publiceert zogeheten metadata waarin een SP die sleutel kan vinden. De metadata is zelf ook weer ondertekend met een sleutel waarmee de SP de herkomst kan controleren (afbeelding 2).

De sleutel
De sleutel

Deze sleutels werden in mei 2019 vijf jaar oud, en sleutels moet je regelmatig vervangen. Echter, naast dat het dus de hoogste tijd was, wilden we ook gelijk een aantal belangrijke verbeteringen realiseren.

Hardware Security Module

We besloten diverse verbeteringen te maken. Het metadata-proces wordt losgetrokken van het inlogproces. Dit stelt ons in staat de metadata op een aparte machine te maken en te ondertekenen, en die te publiceren op een aparte URL. Ook werd deze geïntegreerd met onze internationale metadata-stroom van en naar eduGAIN die daarmee ook volautomatisch kon worden. De metadata wordt in de nieuwe situatie ondertekend met een andere sleutel dan de assertions.

Hardware Security Module
Hardware Security Module

Maar misschien wel de belangrijkste wijziging is dat we voor het ondertekenen van de metadata in de nieuwe situatie gebruik maken van een Hardware Security Module (HSM) – een apparaat dat speciaal ontworpen is om veilig met sleutelmateriaal om te gaan. Het maakt het onmogelijk om de metadata-sleutel te stelen. In ons geval betreft het machines van het Duitse Utimaco. Dezelfde machines gebruikt SURFnet ook voor de DNSSEC-handtekeningen. Het gebruik van een HSM betekende wel dat we helemaal opnieuw moesten beginnen met nieuwe sleutels die vanaf het begin uitsluitend in het apparaat bekend waren, en niet daarbuiten. Het gevolg daarvan weer was dat elke SP deze wijziging moet doorvoeren – feitelijk het vertrouwen in SURFconext opnieuw configureren. Dat klinkt heftig, maar is meestal het aanpassen van twee configuratie-items. Niettemin zou het dus alleen blijven werken als alle SP’s dit ook werkelijk deden – en SURFconext kent op dit moment meer dan achthonderd aangesloten SP’s.

Voortgangsvolgers

Met 884 dienstaanbieders die actie moeten ondernemen is een flag-day-migratie op een vastgestelde datum onhaalbaar. We hebben daarom een vernuftige feature van SURFconext gebruikt. Om een authenticatie te starten roept een SP de SingleSignOn-url van SURFconext aan, die hij ook vindt in de metadata. Nu bevat de nieuwe metadata op de nieuwe locatie een extra parameter van die url: “key:20181213”. De oude metadata bevat die parameter niet. Zo kunnen we al bij het starten van de authenticatie zien op welke metadata de SP zich baseert: nog de oude, of al de nieuwe? In het geval van de nieuwe ondertekenen we het bericht terug naar de SP over succesvolle authenticatie ook direct met de nieuwe sleutel. Zo is de SP op het moment dat hij de nieuwe metadata heeft geconfigureerd, ook al direct ‘over’ naar de nieuwe situatie en is ook meteen duidelijk dat alles op dat moment succesvol werkt. Dit betekent dat elke SP op een zelfgekozen moment de wijziging kan uitvoeren en dan ook klaar is met de migratie.

Data met daarin url: “key:20181213”
url: “key:20181213”

Aanvullend voordeel van deze extra parameter in de nieuwe metadata is dat SURFconext die ook meteen meeneemt in de logging van de betreffende login. En dat stelde ons weer in staat om heel goed de voortgang te volgen, door lijsten en grafieken te maken met het aantal logins per SP via de oude- en de nieuwe sleutel. Zo kunnen we grafieken maken die het percentage van het aantal logins via de nieuwe key weergeven (dat op de deadline natuurlijk 100% moest zijn).

grafiek voortgang keyrollover
grafiek voortgang keyrollover

Communicatie communicatie communicatie

Toen de techniek allemaal klaar stond voor de rollover konden we de communicatie starten. Die werd afgetrapt op 5 februari in een mail naar alle SP’s met instructies. In onze grafieken zagen we een aantal SP’s direct, soms al binnen een uur, actie ondernemen. Hulde! Maar na de eerste week stagneerde het percentage al snel. Toen de deadline naderde, zijn we SP’s elke week gaan mailen, met om de urgentie aan te geven het concrete aantal logins dat we nog voor hen via de oude key zagen. Toen 1 mei nog dichterbij kwam is ons team ook flink in de telefoon geklommen en heeft de lijst met SP’s die nog niet over waren gebeld, met de meestgebruikte natuurlijk eerst. Dit bleek vaak verhelderend – men dacht soms de wijziging al doorgevoerd te hebben. Maar veel vaker nog kwam de reactie “die werkt hier al heel lang niet meer” als we vroegen naar de bij ons bekende contactpersoon. Uiteindelijk is het echter toch nagenoeg altijd gelukt om iemand te pakken te krijgen die de wijziging kon implementeren. Ook hebben we in een aantal gevallen via de instellingen, als “klanten” van de dienst, de nodige wijzigingen kunnen bewerkstelligen.

Ook al hadden we het voor onze gemoedsrust liever anders gezien: in de laatste week voor de deadline zijn nog vele grote SP’s over gegaan naar de nieuwe key. Dit is goed te zien in de grafiek: groen is al over, roze gebruikt nog de oude sleutel. Er kwam in de laatste weken dus veel werk op ons af – laat, maar niet te laat: toen we de oude key op 10 mei ook daadwerkelijk technisch uitschakelden, hebben we nagenoeg geen klachten binnengekregen. Toch een hele prestatie als je 500.000 logins per dag verwerkt, al zeggen we het zelf.

Wat hebben we geleerd?

Volgens planning gaan we het over vijf jaar weer een keer doen. Of misschien wel eerder – want de vorige keyrollover, in 2014, deden we niet omdat de sleutel verlopen was, maar vanwege het fameuze Heartbleed security-incident. Even afkloppen, maar zo’n ongeplande rollover zou natuurlijk weer kunnen gebeuren.

De verwachting is dat het in ieder geval makkelijker zal zijn. We hebben nu, om een grote sprong te kunnen maken, veel in eens veranderd. Als we alleen de sleutels willen vervangen, zal dit de volgende keer alleen vereisen dat men de reeds bekende metadata ‘ververst’ – of dat zelfs al automatisch doet.

Het allerbelangrijkste is echter dat de bij ons bekende contactinformatie toch in veel gevallen gedateerd bleek. Nadat een SP eenmaal is aangesloten worden wij meestal niet meer geïnformeerd over personele wijzigingen. We kijken naar manieren om dit aan te pakken. In ieder geval sturen we vanaf nu aan op functionele adressen (beheer@sp.nl) in plaats van persoonlijke e-mailadressen. We denken ook dat het SP Dashboard meer mogelijkheden geeft om de gegevens actueel te houden. Maar wellicht is het ook een idee periodiek een check naar de contactpersonen te sturen om te zien of ze nog reageren? Ook al zijn er zeker dingen die we beter kunnen doen, toch kan de keyrollover een succes genoemd worden. We hebben een veilige opzet die weer vele jaren mee kan en een veel betere technische basis heeft dan aan het begin van dit jaar hadden. Het vertrouwen is het fundament van de federatie. Alle moeite is dus zeer wel besteed.

Author

Comments

Dit artikel heeft 0 reacties