SAML Single Sign On

Door Ruud Zwanenburg

Kan je met SAML aanmelden op een Windows desktop?

Wat is SAML

SAML staat voor Security Assertion Markup Language. Het is een op XML gebaseerde standaard voor het uitwisselen van authenticatie- en autorisatiegegevens tussen domeinen. Het XML gedeelte wijst er op dat de uitwisseling gebeurt door web services. Authenticatie- en autorisatiegegevens worden gecodeerd door certificaten. Doordat er geen wachtwoord wordt uitgewisseld is dit veilige manier van authentiseren.

Implementatie van SAML

De implementatie van SAML bestaat uit twee delen. Deze twee zijn bij elkaar bekend en vertrouwen elkaar.

• IDP, dit staat voor identity provider. Dit is de database met login gegevens. Hier meld je je aan met je gebruikersnaam en wachtwoord en eventueel Multifactor in welke vorm dan ook. Nadat je geauthentiseerd bent geeft de identity provider dit door aan de service provider.
• SP, dit staat voor service provider. Als je met een webbrowser naar een applicatie toe gaat stuurt deze je door naar de IDP om je te authentiseren. De service provider ontvangt het resultaat hiervan en gebruikt dit om je aan te melden bij de applicatie.

Voordelen

• Single sign on (SSO) naar alle applicaties die SAML ondersteunen.
• Er hoeft geen trust aangemaakt te worden tussen de domeinen.

Nadelen

• Als SSO niet werkt kan je nergens bij. Omdat er geen wachtwoord uitgewisseld wordt, is deze ook niet bekend bij de “Service Provider” en kan je niet even overschakelen op gebruikersnaam en wachtwoord om aan te melden.
• Door XML en certificaten is het lastig te implementeren en trouble shooten.

Waar kennen we SAML van?

Ik denk dat bijna iedereen die een mobiele telefoon heeft al heel vaak wordt geauthentiseerd door middel van SAML zonder dit zelf te weten. Je kan namelijk heel vaak op applicaties aanmelden met je Facebook, Instagram, Fibit of Google-account. En dit werkt meestal met SAML.

Alternatief voor SAML

Een alternatief voor SAML is Auth0. Dit werkt eigenlijk op dezelfde wijze als SAML. Het is een iets nieuwere standaard geïntroduceerd door Google. Google gebruikt Auth0 om aan te melden bij alle Google-applicaties. Daar waar SAML iets meer controle geeft over wat wordt uitgewisseld is Auth0 iets sneller op mobiel en gebruikt JSON.

Schema inloggen SAML

1. Medewerker John opent een web browser en gaat naar website applicatie A
2. Website applicatie A wil weten wie John is en of het echt John is. Website applicatie A heeft zelf geen authenticatie service en stuurt John door naar Identity Provider B in de vorm van een SAML request.
3. Identity Provider B laat John inloggen met naam, wachtwoord en eventueel een vorm van MFA. Als dit succesvol verloopt, encrypt hij dit in een “Assertion“ en stuurt dit terug naar de Service Provider in de vorm van een SAML response. In een assertion zitten ook gegevens van John. Bv een ID of emailadres of eventueel groepslidmaatschappen. Dit moet geconfigureerd worden in de Identity Provider trust tussen IDP en SP. Dit worden, in technische termen, vaak claims genoemd.
4. De Service provider “website applicatie A” decrypt de ontvangen assertion en weet nu dat het inderdaad John is en wat zijn ID of emailadres is. Met deze gegevens laat hij John toe in de applicatie.

Hoe werkt nu precies de laatste stap?

Dit is het stukje waar ik het langst over deed om dit te begrijpen en werkend te krijgen in mijn testomgeving.

De Service Provider weet nu dat John echt John is, omdat hij succesvol bij iemand anders geauthentiseerd is en wat daar zijn ID of emailadres is. Dat ik ook bij Google geauthentiseerd ben, wil in dit geval, niet zeggen dat ik dan bij Microsoft ook iets mag, ook al weten ze wie ik ben.

Dit werkt als volgt

De Service Provider moet zelf een Identity store aanleggen. Hier zit voor elke medewerker een record in met een uniek ID. Dit is meestal en nummer of emailadres. Aan deze medewerker worden rechten gekoppeld, met daarin de informatie over wat ze mogen in de applicatie. Dit noemen ze ook wel “shadow Users”. De ID uit de assertion wordt gekoppeld aan de ID bij de Service Provider. En zo kan de gebruiker aan de slag.

Kan je via SAML authenticatie op een Windows desktop aanmelden?

Als je bij Windows aanmeldt met je gebruikersnaam en wachtwoord ontvang je een kerberos-ticket. Met dit kerberos-ticket krijg je toegang tot resources. Met SAML wordt geen wachtwoord uitgewisseld. Daarom zit daar een uitdaging.

Een andere manier om een kerberosticket te krijgen, is op dezelfde wijze aanmelden als met een smartcard. Je maakt daarbij gebruik van een user certificaat. Je hebt dus voor elke medewerker een “shadow user account” nodig met een bijbehorend user certificaat. Om een user certificaat te krijgen heb je dus ook een certificaat server nodig. Vervolgens koppel je de SAML-name-ID aan de shadow user en certificaat.

Bij Citrix hebben “federated-authentication-service”, dit is de software die dit allemaal regelt.

Wat kan je als identity provider gebruiken.

Er zijn inmiddels veel providers te vinden. Hieronder de bekendste:

• OKTA: Okta is een cloud gebaseerde provider. Het biedt een universal directory die je kan uitbreiden met bv multifactor authenticatie. Geen active directory van Microsoft meer nodig.
• Azure AD: Azure AD is ook in te stellen als IDP. Maak hiervoor een applicatie aan als geen galerij applicatie en kies Single Sign On met als optie SAML.
• Citrix ADC (Netscaler): Citrix ADC is geschikt als IDP of als SP. Als IDP heb je wel een directory nodig waar de ADC met een LDAP query de gebruikers gegevens uit kan halen. Daar kan je bijvoorbeeld je on premisse Active Directory voor gebruiken.
• Amazon web services
• Social media: En natuurlijk ook de sociaal media als facebook en Google, maar ik denk niet dat je die voor een bedrijf wil gebruiken.