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.

Handige links

Oasis
SAML Developers tools
Citrix FAS
OKTA
Amazon web services

Meer weten?

Wil je meer weten over SAML, neem dan gerust contact met ons op.

Citrix Web App Firewall op Application Delivery Controller (Netscaler)

Zo wordt de lancering van een nieuw systeem wel een succes

Als verantwoordelijke voor een IT-project is het moment van in gebruik name van een systeem altijd een spannend moment. Manfred Rothfusz, Technisch Consultant bij Login Consultants, vertelt in deze blog hoe je vooraf performance en continuïteit van je nieuwe systeem kunt waarborgen.

Wachten op het oordeel

Als je een nieuw systeem in gebruik neemt, is het altijd maar de vraag hoe je gebruikers de verandering gaan ervaren en of de performance aan hun verwachtingen voldoet. Natuurlijk heb je het systeem getest, maar hoeveel functioneel beheerders en keyusers je ook bij de test betrekt, het is altijd afwachten wat het oordeel gaat zijn van de uiteindelijke, veel grotere, gebruikersgroep op het moment dat ze de nieuwe omgeving gaan gebruiken. Misstappen kunnen leiden tot veel kritiek en gezichtsverlies, zelfs tot in de media.

Pijnpunten blootleggen en verhelpen

Door gebruik te maken van grote groepen gesimuleerde medewerkers die gescripte werkzaamheden uitvoeren, kun je inzicht krijgen in de responsetijden die zij ervaren. Door die responsetijden te analyseren, kunnen pijnpunten in je ICT-infrastructuur worden blootgelegd en kan aan een oplossing worden gewerkt.

Geen gezichtsverlies

Zo hebben we bijvoorbeeld een grote overheidsinstelling behoed voor gezichtsverlies. Voordat de ingebruikname van haar nieuwe omgeving hebben we deze belast met duizenden gesimuleerde medewerkers. Tijdens de eerste test bleek dat bij zo’n dertig procent van die gesimuleerde medewerkers de omgeving zo traag reageerde dat werken onmogelijk werd. Als de medewerkers, zoals gepland, in kleine groepen gemigreerd zouden zijn, was er uiteindelijk een performanceprobleem ontstaan. Dan had men de migratie moeten stoppen en het probleem gaan onderzoeken, wat naar alle waarschijnlijkheid maanden had geduurd. Doordat er vooraf met gesimuleerde medewerkers getest is, kon het probleem aangepakt worden voor de lancering. Nadat de hardwarecapaciteit met zo’n vijftig procent was uitgebreid, werkte de test met de duizenden gesimuleerde medewerkers wel goed en kon de nieuwe omgeving zonder problemen in gebruik worden genomen.

Nieuw Elektronisch Patiënten Dossier

Een ander voorbeeld is de ingebruikname van één nieuw Elektronisch Patiënten Dossier (EPD) door twee universitaire ziekenhuizen. Het is onmogelijk om een nieuw EPD te gebruiken naast een bestaande, dus een bigbang-migratie was onvermijdelijk. Door duizend artsen, tweeduizend polimedewerkers, tweeduizend verpleegkundigen te simuleren en deze in twee uur tijd 25 duizend denkbeeldige patiënten te laten raadplegen – veel meer dan in de praktijk ooit voorkomt – werd duidelijk dat de performance en continuïteit gewaarborgd was. Dat gaf zoveel vertrouwen, dat het zorgde voor een Go vanuit de ICT-organisatie voor de migratie van het EPD.

Gokken is dokken

Mijn stokpaardje is ‘meten is weten, gissen is missen en gokken is dokken’. In de praktijk blijkt dit maar al te vaak te kloppen. Door vooraf met gesimuleerde medewerkers te testen kan de performance en continuïteit nauwkeurig in kaart gebracht worden. Deze aanpak bewijst zich niet alleen bij het in gebruik nemen van een nieuwe omgeving, maar ook bij bijvoorbeeld Microsoft updates, nieuwe versies van een transactiesysteem of van een bedrijfskritieke applicatie. Door te voorspellen laat de ICT-organisatie aan de gebruikersorganisatie zien dat ze in control zijn en wordt de kans op calamiteiten geminimaliseerd.

Benieuwd?

Nieuwsgierig geworden naar de kansen en mogelijkheden van dergelijke simulaties? Neem vrijblijvend contact met ons op. We denken graag met je mee.

 

Updates, fixes en controle-script voor beveiligingsprobleem Citrix Netscaler

Resterende Citrix fixes beschikbaar

De resterende permanente fixes voor de eerder geïdentificeerde kwetsbaarheid bij Citrix, zijn nu beschikbaar voor alle klanten.

Citrix-script beschikbaar voor controle op misbruik

Citrix heeft een script beschikbaar gesteld, waarmee je kunt controleren op misbruik of het compromitteren van de NetScaler

Meer informatie hierover kun je lezen in dit blog: Citrix and FireEye Mandiant share forensic tool for CVE-2019-19781

Updates: Beveiligingsprobleem Citrix NetScaler – fixes en controle-script

Citrix heeft een fix uitgebracht voor de problemen met de NetScaler versies 11.1 en 12.0

https://www.citrix.com/downloads/citrix-adc/

In december heeft Citrix een ernstige kwetsbaarheid in NetScaler bekend gemaakt. Door dit beveiligingsprobleem kunnen kwaadwillende toegang krijgen tot het bestandssysteem van de NetScaler om zo gebruikers te besmetten met malware, ransomware aanvallen uit te voeren of botnet functionaliteiten toe te voegen.

Citrix heeft direct mitigatie maatregelen aangeboden. Nu blijkt dat deze niet effectief zijn voor alle release versies van NetScaler. Zit je op release 12.1 van NetScaler en is de buildversie 12.1 51.19 of lager dan is het mogelijk dat deze maatregelen niet of niet goed werken.

Ons advies:

  • Implementeer de mitigerende maatregelen zoals aangegeven door Citrix: https://support.citrix.com/article/CTX267679
  • Als je gebruik maakt van NetScaler release 12.1 en de build is 51.19 of lager, voer een upgrade uit naar de laatste versie van release 12.1

Als je vermoedt dat de omgeving al is aangevallen? Onderneem dan de volgende stappen

uit /var/log

  • log kijk naar commando’s die misbruikt kunnen worden zoals curl, hostname, uname, whoami of commando’s die gerund worden onder nobody
  • log, kijk hier naar verdachte activiteiten
  • log, httperror.log, hier staan de IP adressen van de aanvallers ingelogd, aangezien de aanval geschiedt over de web interface, zoek naar http log berichten waar /vpn in de directory traversal aanval staan

Zoek naar aangepaste bestanden in

  • /netscaler/portal/templates
  • /var/tmp/netscaler/portal/templates

Kijk naar de draaiende processen, specifiek of er niet verdachte “child” processen zijn, vooral draaiend onder nobody

Kijk of er cronjobs zijn met de eigenaar nobody