Single Sign-On (SSO)

In de huidige digitale wereld, waarin we dagelijks talloze applicaties en platforms gebruiken, is het beheren van verschillende inloggegevens een uitdaging geworden.

Het continu in- en uitloggen bij verschillende systemen kan tijdrovend en frustrerend zijn, en het onthouden van meerdere wachtwoorden kan leiden tot onveilige praktijken, zoals het gebruik van te eenvoudige wachtwoorden of het opschrijven van wachtwoorden.

Hier komt Single Sign-On (SSO) in beeld.  In dit artikel gaan we dieper in op wat SSO is, hoe het werkt, en waarom het zo belangrijk is in de hedendaagse digitale omgeving.

Wat is Single Sign-On (SSO)?

Single Sign-On, kortweg SSO, is dat eindgebruikers zich eenmalig hoeven in te loggen. De SSO-software zorgt er daarna voor dat authenticatie tot andere applicaties automatisch verloopt.

Dit betekent dat gebruikers na het inloggen in één applicatie, automatisch toegang krijgen tot alle andere applicaties waarvoor ze geautoriseerd zijn, zonder dat ze opnieuw hoeven in te loggen.

Dit is een aanzienlijke verandering ten opzichte van enkele jaren geleden, toen een kleine set applicaties alles was wat een gebruiker nodig had om zijn werk te doen.

In de huidige digitale omgeving, waarin gebruikers vaak toegang moeten hebben tot tientallen verschillende applicaties, biedt SSO een efficiënte en gebruiksvriendelijke oplossing voor het beheer van toegangsrechten.

Voordelen van Single Sign-On (SSO)

• Gebruiksgemak: Gebruikers hoeven slechts één set inloggegevens te onthouden, wat het inlogproces vereenvoudigt en versnelt.
• Verhoogde productiviteit: Minder tijd besteed aan inloggen betekent meer tijd voor daadwerkelijk werk.
• Verbeterde beveiliging: Door het verminderen van het aantal inloggegevens dat moet worden onthouden, vermindert SSO de kans op onveilige wachtwoordpraktijken.
• Efficiënt beheer van toegangsrechten: Beheerders kunnen gemakkelijk beheren welke gebruikers toegang hebben tot welke applicaties, allemaal vanuit één centraal punt.
• Minder IT-ondersteuning: Met minder vergeten wachtwoorden om te resetten, kunnen IT-teams hun tijd besteden aan belangrijkere taken.

Nadelen van Single Sign-On (SSO)

• Enkelvoudig falen: Als de SSO-oplossing uitvalt, kunnen gebruikers mogelijk geen toegang krijgen tot enige applicatie.
• Beveiligingsrisico’s: Als de inloggegevens van een gebruiker worden gecompromitteerd, kan een aanvaller mogelijk toegang krijgen tot alle applicaties waarvoor de gebruiker is geautoriseerd.
• Compatibiliteitsproblemen: Niet alle applicaties ondersteunen SSO, wat kan leiden tot inconsistenties in de gebruikerservaring.

Het risico van Single Sign-On is dat wanneer je eenmaal ingelogd bent je overal toegang toe hebt. Het wordt daarom sterk aanbevolen om elke SSO-oplossing te combineren met een extra niveau van authenticatie (Two Factor Authentication).

Hoe veilig is SSO?

Single Sign-On (SSO) is ontworpen om zowel de gebruiksvriendelijkheid als de beveiliging te verbeteren. Door het aantal inloggegevens dat gebruikers moeten onthouden te verminderen, vermindert SSO de kans op onveilige wachtwoord praktijken, zoals het gebruik van te eenvoudige wachtwoorden of het opschrijven van wachtwoorden.

Bovendien kunnen beheerders met SSO gemakkelijk controleren en beheren welke gebruikers toegang hebben tot welke applicaties, wat helpt om ongeautoriseerde toegang te voorkomen.

Echter, zoals bij elke beveiligingsoplossing, is SSO niet zonder risico’s. Als de inloggegevens van een gebruiker worden gecompromitteerd, kan een aanvaller mogelijk toegang krijgen tot alle applicaties waarvoor de gebruiker is geautoriseerd. Daarom is het belangrijk om SSO te combineren met andere beveiligingsmaatregelen, zoals sterke wachtwoordvereisten, regelmatige wachtwoord wijzigingen, en mogelijk zelfs Multi-Factor Authenticatie (MFA).

MFA is een beveiligingsmethode waarbij gebruikers twee of meer bewijsstukken (of factoren) moeten leveren om hun identiteit te verifiëren. Deze factoren kunnen iets zijn dat de gebruiker weet (zoals een wachtwoord), iets dat de gebruiker heeft (zoals een beveiligingstoken of een mobiel apparaat), of iets dat de gebruiker is (zoals een vingerafdruk of een ander biometrisch kenmerk). Door SSO te combineren met MFA, kunnen organisaties de gebruiksvriendelijkheid van SSO bieden, terwijl ze tegelijkertijd een hoger niveau van beveiliging handhaven.

Er zijn ook alternatieven voor SSO, zoals federated identity management, waarbij identiteitsinformatie wordt gedeeld tussen verschillende organisaties, en risk-based authentication, waarbij het authenticatieniveau wordt aangepast op basis van het risiconiveau van de gebruiker en de transactie. Echter, deze oplossingen hebben hun eigen voor- en nadelen en kunnen complexer zijn om te implementeren dan SSO.

Voor wie op zoek is naar een complete oplossing die zowel gebruiksvriendelijk als veilig is, kan HelloID de ideale keuze zijn. Met HelloID kan men profiteren van de voordelen van SSO, terwijl ook andere geavanceerde beveiligingsfuncties kunnen worden geïmplementeerd, zoals Multi-Factor Authenticatie. Neem vandaag nog contact op om te ontdekken hoe HelloID kan helpen.

Download whitepaper over security

Hoe functioneert Single Sign-On?

Het basisidee van SSO is dat elke toepassing die een persoon nodig heeft toegankelijk is door zich eenmalig bekend te maken. Applicaties moeten dus op een of andere manier weten dat je al gevalideerd bent. Met een goede SSO-oplossing hebben moderne applicaties geen kopie van de inloggegevens, maar vertrouwen die eenvoudig op wat een identiteitsprovider (IdP) wordt genoemd.

Voordat we toelichten hoe dit werkt, behandelen we eerst de terminologie en bijbehorende definities.

Om een applicatie te gebruiken of toegang te krijgen tot een beveiligd netwerk, moet je jezelf kunnen identificeren. Dit gebeurt vaak met een combinatie van een unieke gebruikersnaam en een wachtwoord. De combinatie van een gebruikersnaam en wachtwoord is een vorm van authenticatie.

Identiteitsprovider (IdP):
Dit is waar inloggegevens worden opgeslagen. Alle authenticatie gebeurt hier. Een identiteitsprovider kan bijvoorbeeld de lokale Active Directory zijn, Azure AD of bijvoorbeeld onze Cloud IDaaS oplossing HelloID.

Serviceprovider (SP):
Dit is het systeem of toepassing waartoe een gebruiker toegang heeft en die verificatie vereist. Wanneer een gebruiker een toepassing opent, praten de service- en identiteitsproviders met elkaar om de identiteit van de gebruiker te verifiëren. Als de identiteitsprovider de gebruiker positief identificeert, worden ze toegelaten tot de toepassing.

Bewering:
Een bewering is een pakket met informatie dat wordt verzonden van de IdP naar de SP. De inhoud van een bewering varieert per SSO-protocol (bijvoorbeeld SAML, OAuth of OpenID), maar bevat meestal de unieke ID, naam en verschillende andere attributen. Deze is ondertekend en gecodeerd door een certificaat waartoe zowel de IdP als de SP toegang hebben. Hiermee kan de SP ervoor zorgen dat de informatie afkomstig is van een vertrouwde bron.Om een ​​applicatie te gebruiken of toegang te krijgen tot een beveiligd netwerk, moet je jezelf kunnen identificeren. Dit gebeurt vaak met een combinatie van een unieke gebruikersnaam en een wachtwoord. De combinatie van een gebruikersnaam en wachtwoord is een vorm van authenticatie.

Hier is een gedetailleerd overzicht van hoe SSO werkt:

1. Gebruikersauthenticatie: De gebruiker logt in op een centrale authenticatieserver, ook wel bekend als de Identity Provider (IdP). Dit kan bijvoorbeeld de lokale Active Directory zijn, Azure AD of bijvoorbeeld onze Cloud IDaaS oplossing HelloID.
2. SSO-sessie: Na een succesvolle authenticatie start de IdP een SSO-sessie. Dit wordt meestal gedaan door een cookie in de browser van de gebruiker te plaatsen.
3. Toegang tot applicaties: Wanneer de gebruiker een toepassing opent, praten de service- en identiteitsproviders met elkaar om de identiteit van de gebruiker te verifiëren. Als de identiteitsprovider de gebruiker positief identificeert, worden ze toegelaten tot de toepassing.
4. Authenticatiecontrole: De IdP controleert de SSO-sessie. Als de gebruiker al geauthenticeerd is, stuurt de IdP een bewering naar de SP met de authenticatiegegevens van de gebruiker. Deze bewering is ondertekend en gecodeerd door een certificaat waartoe zowel de IdP als de SP toegang hebben.
5. Toegang verlenen: Op basis van de ontvangen bewering verleent de SP de gebruiker toegang tot de applicatie zonder dat de gebruiker opnieuw hoeft in te loggen. Hierdoor hoeven SP’s geen inloggegevens logisch op te slaan.

Het is belangrijk op te merken dat dit een vereenvoudigd overzicht is en dat de specifieke stappen kunnen variëren afhankelijk van de gebruikte SSO-oplossing en de configuratie van de applicaties.

 

Makkelijk gezegd werkt SSO door een gevestigd vertrouwen tussen de identiteitsprovider (IdP) en de serviceprovider (SP). Dit betekent dat wanneer de IdP zegt dat de persoon die de applicatie gebruikt ‘Jan Jansen’ is, de SP dit gelooft en de gebruiker onder het account van ‘Jan Jansen’ logt.

Dit vertrouwen wordt vastgesteld door de beheerder van de systemen. Informatie van de IdP wordt doorgegeven aan de SP samen met een certificaat en vice versa. Wanneer een gebruiker een toepassing opent, gebruikt de IdP het certificaatteken en codeert een bewering. Deze bewering wordt vervolgens verzonden naar de SP in plaats van de inloggegevens van de gebruiker. De SP zorgt ervoor dat dit wordt ontcijferd en geverifieerd.

Door deze vertrouwensrelatie tot stand te brengen hoeven SP’s geen inloggegevens logisch op te slaan.

Hoe werkt Single Sign-On in de praktijk?

Bovenstaand is toegelicht hoe SSO in het algemeen kan functioneren. Maar hoe werkt dit in de praktijk: hoe gaat een gebruiker om met het openen van een applicatie en hoe weet een SP dat hij moet controleren met de IdP?

De meeste Single Sign-On IdP’s worden geleverd met toepassingsportals. Dit zijn vaak webgebaseerde applicaties waar gebruikers overal ter wereld toegang toe hebben. Zodra een gebruiker zich met zijn inloggegevens bij het portaal aanmeldt, krijgt hij toegang tot alle applicaties en resources die hij nodig heeft om zijn werk uit te voeren. Nadat de gebruiker een toepassing heeft gekozen, wordt een SSO-bevestiging naar de SP gestuurd met de informatie van de gebruiker. Als de bewering wordt geaccepteerd, wordt de gebruiker naar de toepassing gebracht en kan hij direct aan slag! Dit type SSO-activiteit wordt ‘IdP geïnitieerd’ genoemd, omdat het afkomstig is van de identiteitsprovider (IdP) zelf.

Maar wat als de gebruiker niet eerst naar het portaal gaat? Wat gebeurt er bijvoorbeeld als hij via zijn browser direct naar Gmail gaat? In dergelijke gevallen weet de SP wat hij moet doen op basis van de gebruikersnaam of het emaildomein van de gebruiker. In plaats van referenties slaat de SP de informatie van de IdP op en weten ze waar ze de authenticatieaanvraag moeten routeren. Dit type verzoek wordt “SP Initiated” genoemd, omdat het SSO-verzoek afkomstig was van de serviceprovider (SP).

[1] https://www.businesswire.com/news/home/20170918005033/en/Information-App-Overload-Hurts-Worker-Productivity-Focus

Meer over Cloud Single Sign-On