In de eerste blog van deze serie is Entree Federatie geïntroduceerd als een voorbeeld van een federatief authenticatieplatform. Door de inzet van dit platform wordt het onder andere mogelijk gemaakt voor gebruikers (bijvoorbeeld scholieren) om in te loggen bij verschillende dienstleveranciers (zoals leveranciers van leermiddelen). Maar wat is een federatief authenticatieplatform precies?
Een federatief authenticatieplatform levert een gecentraliseerde oplossing voor het verwerken van authenticaties (succesvolle inlogverzoeken) tussen verschillende partijen. Afnemers van de dienst hoeven hierdoor maar aan één platform te koppelen om toegang te krijgen tot de aangesloten dienstleveranciers binnen een federatie. Dienstleveranciers op hun beurt kunnen door te koppelen met een federatie alle aangesloten instellingen (bijvoorbeeld scholen) bedienen. Bovendien kunnen gestandaardiseerde afspraken waarbij beveiliging en privacy van de gebruikers centraal staan, gecentraliseerd worden afgedwongen.
Naast het feit dat partijen maar aan één platform hoeven te koppelen, maakt het hebben van een federatie Single Sign-On (SSO) mogelijk. Door middel van SSO hoeven gebruikers slechts één keer in te loggen bij de federatie. Daarna is de gebruiker bekend binnen de federatie en kan deze (binnen een bepaalde tijdspanne) toegang krijgen tot alle beschikbare diensten zonder opnieuw te hoeven inloggen.
Technische werking – Hub-and-Spoke-model
Er zijn twee gangbare modellen beschikbaar om binnen een federatie koppelingen tussen aangesloten partijen te maken: het Mesh-model en het Hub-and-Spoke-model.
Het Mesh-model voorziet in onderlinge koppelingen tussen alle aangesloten partijen (nodes). Dit decentrale model kent als voordeel dat er geen centrale node benodigd is. Een storing bij een van de nodes binnen dit model heeft zodoende geringe impact. Het nadeel van het Mesh-model is dat bij uitbreiding van een federatie met een nieuwe node, elke bestaande node een additionele koppeling dient aan te maken. Het ontbreken van standaardisatie in de configuratie is daarbij een potentieel risico. Verder lopen de kosten met elke aansluiting van een nieuwe node voor alle betrokken partijen op.
Het koppelen van veel verschillende partijen wordt binnen het Mesh-model zodoende al snel complex. Entree Federatie maakt daarom gebruik van het Hub-and-Spoke-model. In dit model staat een Hub centraal waarin alle informatie rondom de authenticatie tussen de aangesloten partijen/nodes – de zogenoemde Spokes – wordt verwerkt.
In dit model is er geen sprake van (directe) communicatie tussen de Spokes. Alle communicatie, vanuit het perspectief van een authenticatieproces, verloopt via de Hub. In praktisch opzicht betekent dit dat elke Spoke slechts één connectie hoeft te onderhouden, namelijk met de Hub. Een uitbreiding van een federatie op basis van het Hub-and-Spoke-model vereist zodoende geen acties vanuit de andere Spokes. Specifieke (toegangs)configuratie van een Spoke met een andere Spoke binnen een dergelijke federatie dient te worden geadministreerd vanuit de Hub zelf, of een daarvoor beschikbaar gestelde applicatie. Vanuit kostenperspectief kent de aansluiting van een nieuwe Spoke zodoende een lineair verloop. Het aansluiten van een nieuwe Spoke is daarmee (veel) goedkoper dan in een Mesh-variant.
Entree Federatie: een Hub-and-Spoke-federatie
Entree Federatie hanteert een Hub-and-Spoke-model. Hierbij wordt onderscheid gemaakt tussen twee typen Spokes: Identity Providers en Service Providers (dienstverleners).
Een Identity Provider vertegenwoordigt één of meerdere scholen. Een scholier of leerkracht van een school kan zich bij de desbetreffende Identity Provider authenticeren met een gebruikersnaam en een wachtwoord, en eventueel een eenmalige code (‘multi-factor authentication’). Bij een succesvolle authenticatie worden zogenoemde attributen van de gebruiker (zoals voornaam, achternaam en instellingsgegevens) doorgegeven aan Entree Federatie. Op basis van deze gegevens assembleert Entree Federatie een binnen de federatie uniek kenmerk.
Een Service Provider biedt één of meerdere diensten aan via Entree Federatie. Middels SSO kunnen gebruikers eenvoudig gebruikmaken van verschillende diensten. Echter, verschillende diensten vereisen verschillende informatie van de gebruiker. Omdat de privacy van de gebruiker centraal staat, wordt er gebruikgemaakt van de zogenoemde Attribute Release Policy (ARP). Elke dienst dient zijn eigen (ARP-)lijst aan benodigde informatie (attributen) op te geven om aan te sluiten op Entree Federatie. Door de ARP toe te passen gedurende het authenticatieproces, wordt tijdens de verwerking van de data alleen de (minimaal) noodzakelijke informatie doorgestuurd naar de desbetreffende dienst.
Hoe verloopt een authenticatieproces binnen Entree Federatie?
Entree Federatie maakt primair gebruik van het SAML 2.0-protocol voor het uitwisselen van authenticatie-informatie met Identity Providers en Service Providers. Het huidige platform maakt daarbij gebruik van de in Java geschreven authenticatie-engine Asimba (op basis van de open-source library OpenSAML). Feitelijk gedraagt de engine zich als een Service Provider richting Identity Providers, en als Identity Provider richting Service Providers.
Doorgaans begint de ‘user journey’ bij het bezoeken van een dienst waar bijvoorbeeld leermiddelen beschikbaar zijn. Vervolgens vereist deze dienst dat de gebruiker zich kenbaar maakt (zich authenticeert; ‘wie ben jij?’). Om deze informatie te verkrijgen stuurt de Service Provider de gebruiker door naar Entree Federatie. Vervolgens toont Entree Federatie de gebruiker een Where-Are-You-From (WAYF)-scherm waarop de gebruiker de Identity Provider kan selecteren waar zijn/haar school bij is aangesloten. Entree Federatie stuurt de gebruiker door naar deze Identity Provider, en na een succesvolle authenticatie ontvangt Entree Federatie de attributen van de gebruiker. De ARP van de Service Provider wordt vervolgens toegepast en de gefilterde attributen plus het unieke kenmerk van de gebruiker binnen Entree Federatie worden gedeeld met de Service Provider. De Service Provider kan vervolgens de gebruiker autoriseren op basis van de attributen. Authenticatie en autorisatie zijn zodoende gescheiden en de Service Provider behoudt controle over de toegang tot de applicatie. De gebruiker heeft zich nu succesvol aangemeld bij de dienst en kan hiervan gebruik gaan maken.
Bovenstaande geeft een gesimplificeerd overzicht van een succesvol authenticatieproces. Veel complexiteit zit echter in de uitzonderingssituaties: herauthenticaties, expliciete (her)inlogverzoeken, inlogverzoeken waarbij een Identity Provider vooraf is geselecteerd (scoping), time-outsituaties en protocolfouten. Vanuit technisch perspectief wordt voor deze situaties gebruikgemaakt van de mogelijkheden die worden geboden vanuit de SAML 2.0-standaard in combinatie met de implementatie hiervan in de OpenSAML library.
