Wat is Single Sign On, wat is het niet, en hoe werkt het echt!

SSO: Foute benamingen

Single Sign On, een magisch woord in hedendaagse versprokkelde omgevingen.. Echter wordt ook dit toverwoord vaak verkeerd gebruikt, en bedoelt men eigenlijk iets anders.

Bij veel gebruikers leeft het idee dat Single Sign On (hierna SSO) inhoudt dat overal hetzelfde gebruikersnaam en wachtwoord voor wordt gebruikt.
Weer anderen denken zelfs dat wanneer men gebruik maakt van identieke gebruikersgegevens men nog maar een enkele keer hoeft aan te melden.
Ook wordt het uitbesteden van een authenticatievraag via SAML als SSO bestempeld. (Sorry Google) Het uitbesteden van authenticatie naar een enkele overkoepelende partij is beter bekend onder 'Federated Authentication' en staat een gebruiker toe zijn inloggegevens van het bedrijf te gebruiken op een webpagina buiten het bedrijf. Via SAML wordt er een authenticatievraag naar het bedrijf gestuurd waarna een goedkeuring of foutmelding retour komt.



Echte SSO is een methode die de gebruiker in staat stelt om met slechts een enkele keer aanmelden, toegang te kunnen verkrijgen tot resources en andere systemen, zelfs als deze systemen gebruik maken van een andere authenticatie databank.

Ik onderscheid hierin twee verschillende vormen van SSO:

• Impliciete Single Sign On
• Explicitete Single Sign On

Impliciete Single Sign On:

Deze vorm van SSO wordt vaker gebruikt dan de gemiddelde gebruiker doorheeft. Het gebeurt allemaal onder water. Wanneer je bent ingelogd op je Windows werkplek op kantoor, en je wilt toegang tot die ene netwerkdrive.. Hier gebruikt Windows het Kerberos protocol om vast te stellen dat je reeds bent 'geauthenticeerd', en krijg je een tijdelijk token waarmee je de netwerkdrive mag benaderen.
Een ander voorbeeld wat ook een mooie vorm is van impliciete SSO, is de aanmelding op Google's GMail, Calendar, Drive, Picasa etc. Je hoeft slechts 1x tegen Google te bewijzen wie je bent, en daarna heb jij toegang tot alle systemen van Google waar jij voor geautoriseerd bent. Dit werkt op basis van een sessie cookie die je in je Internet Browser actief hebt.

Expliciete Single Sign On:

Deze vorm van Single Sign On vereist actie van de gebruiker of van zijn systeembeheerder om dit werkend te krijgen. Meestal vereist dit een extra stuk software (al dan niet gekoppeld met een stukje hardware/token) welke wordt ingeregeld om alle aanmeldingen voor een gebruiker te voltooien. De gebruiker 'ziet' soms niet eens meer een aanmeldscherm, maar is direct ingelogd na het starten van een applicatie.

Voorbeelden hiervan zijn Imprivata OneSign, Citrix Password Manager, en de steeds bekender wordende YubiKey.
Deze implementaties 'herkennen' het inlogscherm, vullen de gebruikersnaam en het wachtwoord voor de gebruiker in, en versturen deze zodat de gebruiker het idee heeft dat hij niet meer in hoeft te loggen.

Het mooie hiervan is dat deze software ook geprogrammeerd kan worden om de schermen te  'herkennen' welke de gebruiker vertelt dat hij zijn wachtwoord moet aanpassen. Op dat moment neemt deze software het heft in eigen handen en stelt een nieuw - voor de gebruiker onbekend - wachtwoord in.

Een vrij nieuwe speler op de markt komt ook uit de hoek van Citrix. Dit betreft de AppController, een onderdeel uit de Citrix CloudGateway Enterprise Suite. Dit specifieke onderdeel maakt het onder andere mogelijk om vanuit een enkel webportaal (StoreFront), web/SaaS applicaties op te starten zonder dat de gebruiker hierbij apart hoeft in te loggen. Dit is vergelijkbare functionaliteit met de hierboven benoemde SSO oplossingen, behalve dat dit geen extra software op de cliënt vereist. Zelfs het aanmaken (provisioning) en afvoeren (deprovisioning) van gebruikers kan hiermee worden geautomatiseerd.

De risico's van SSO:

Hoewel de gebruiker vaak erg blij is met een goede implementatie van SSO, levert het ook de nodige risico's. Vaak gebeurt het dat een gebruiker even weg is van zijn werkplek, zonder dat deze wordt vergrendeld. Dit laat een ongeautoriseerd persoon de mogelijkheid om die ene salaris applicatie te starten om te achterhalen met welk bedrag zijn collega aan het eind van de maand naar huis gaat te controleren, of erger nog, aan te passen.

Natuurlijk heeft dit met een stukje gebruikersopvoeding te maken - en dan doel ik op het vergrendelen van de werkplek bij het verlaten - maar toch is het iets waar over nagedacht moet worden.

Keuze voor een SSO oplossing zou dus ook moeten inhouden dat het mogelijk is om een selectie van applicaties uit de SSO oplossing te laten, of - in het geval van impliciete SSO - er om een extra authenticatie voor te vragen.