SAML single sign-on voor je LMS instellen met Entra ID, Okta of Google Workspace

Elke aparte login is weer een wachtwoord om te resetten en weer een account om te sluiten als iemand vertrekt. SAML single sign-on (SSO) koppelt je learning management system aan je identiteitsprovider, zodat mensen met hun werkaccount inloggen voor trainingen en toegang je directory volgt. Hier lees je hoe SAML werkt, hoe het instellen met Microsoft Entra ID, Okta of Google Workspace verloopt en wat je controleert voordat je live gaat.

Hoe SAML single sign-on werkt

SAML (Security Assertion Markup Language) 2.0 is een open standaard om inloggegevens door te geven tussen twee systemen die elkaar vertrouwen. Het LMS ziet het wachtwoord van de persoon nooit: het stuurt hem of haar naar je identiteitsprovider, die vaststelt wie het is, met de meerfactorauthenticatie die je eist, en die de persoon terugstuurt met een ondertekende verklaring.

Assertions zijn kortlevend en noemen hun doelgroep (de entity ID van de SP). De SP weigert alles wat verlopen is of voor een andere applicatie bedoeld was.

Waarom SSO de moeite waard is voor een LMS

• Geen extra wachtwoorden. Mensen gebruiken hun dagelijkse account en je MFA en toegangsbeleid gelden ook voor training.
• Nieuwe medewerkers krijgen snel toegang. Wijs de LMS-applicatie toe aan een groep en nieuw personeel daarin kan op dag één inloggen.
• Vertrekkende medewerkers verliezen toegang aan de bron. Schakel iemand uit in je directory en die persoon kan geen nieuwe LMS-sessie meer starten. SAML regelt het inloggen, niet het account, dus archiveer het LMS-account ook als onderdeel van het uitdienstproces.

Just-in-time accounts aanmaken

Bij just-in-time (JIT) provisioning maakt het LMS een account aan de eerste keer dat iemand inlogt, op basis van de attributen in de assertion, zodat er geen gebruikerslijst hoeft te worden geïmporteerd. Leg er waarborgen omheen:

• Beperk het tot je eigen e-maildomeinen, zodat een verkeerd geconfigureerde applicatie of gastaccount geen ongewenste gebruikers aanmaakt.
• Geef nieuwe accounts de laagste rol en verleen beheerdersrechten bewust.
• Koppel mensen op een stabiele identificatie als je IdP die kan sturen, want e-mailadressen veranderen.

SP-initiated versus IdP-initiated inloggen

• SP-initiated: de persoon opent het LMS, dat een authenticatieverzoek naar de IdP stuurt, en de IdP post zijn antwoord naar de ACS URL. Het werkt vanuit bladwijzers en links in e-mails en wordt over het algemeen als de veiligere route beschouwd, omdat het antwoord hoort bij een verzoek dat het LMS zelf deed.
• IdP-initiated: de persoon klikt op de tegel van de applicatie in Microsoft Mijn apps, het Okta-dashboard of het Google-appmenu en de IdP stuurt een niet-aangevraagd antwoord naar de ACS URL.

Je kunt beide aanbieden; test ze allebei.

SAML-SSO instellen, stap voor stap

De volgorde is overal ongeveer hetzelfde:

1. Bepaal de reikwijdte: wie SSO gebruikt, welke groepen de applicatie krijgen, welke e-maildomeinen zijn toegestaan en welk attribuut elke persoon identificeert.
2. Maak de koppeling aan in het LMS en noteer de entity ID en ACS URL.
3. Maak een SAML-applicatie bij je IdP met die waarden, kies het NameID-formaat en voeg attributen toe voor e-mailadres, voornaam en achternaam.
4. Wijs gebruikers of groepen toe; niet-toegewezen mensen worden meestal geweigerd.
5. Geef het LMS de gegevens van de IdP: een metadata-URL, een metadatabestand, of de entity ID, inlog-URL en het ondertekeningscertificaat van de IdP.
6. Koppel de attributen aan de namen die je IdP werkelijk stuurt.
7. Test en schakel het dan in, en vertel mensen wat er verandert.

Opmerkingen per provider

De documentatie van je provider bevat de exacte schermen. Goed om te weten:

• Microsoft Entra ID: gebruik een enterprise-applicatie die niet uit de galerij komt, geen app-registratie, want die biedt geen SAML. Claimnamen zijn lange URI’s, dus kopieer ze exact. De object-ID is een goede stabiele identificatie. Voor mensen zonder mailbox kan de e-mailclaim leeg zijn; de user principal name kan die vervangen als het een echt adres is.
• Okta: maak een SAML 2.0-app-integratie. Je benoemt de attribuutverklaringen zelf, dus ze moeten exact overeenkomen met de koppeling in het LMS, inclusief hoofdletters. De interne gebruikers-ID van Okta is een stabiele identificatie.
• Google Workspace: voeg een aangepaste SAML-app toe en download het metadatabestand. De app staat aanvankelijk uit, dus schakel hem in voor de juiste organisatie-eenheden of groepen. Een gebruikelijke opzet identificeert mensen op hun primaire e-mailadres, dus houd rekening met hernoemde en hergebruikte adressen.

Testchecklist

Controleer dit vóór livegang in een privévenster van de browser:

• Een bestaande gebruiker logt in vanuit het LMS en nogmaals vanuit de apptegel.
• Een nieuwe gebruiker op je domein krijgt een account met de juiste rol.
• Iemand die niet aan de applicatie is toegewezen, wordt geweigerd.
• Iemand buiten je toegestane domeinen wordt geweigerd.
• E-mailadres, voornaam en achternaam komen correct aan.
• Een beheerder kan nog steeds binnenkomen via de noodroute.

Veelvoorkomende valkuilen

Tijdverschil tussen klokken (clock skew)

Als de klokken van de IdP en het LMS meer uiteenlopen dan het LMS tolereert, worden goede assertions geweigerd als nog niet geldig of al verlopen. Het treft vooral zelf gehoste identiteitsservers, dus houd hun klokken gesynchroniseerd.

Verlopen en vernieuwen van certificaten

Ondertekeningscertificaten van de IdP verlopen en als het LMS het nieuwe niet vertrouwt, mislukt elke aanmelding in één keer. Zet de vervaldatum in je agenda. Kan je LMS twee certificaten vertrouwen, voeg dan eerst het nieuwe daar toe en activeer het daarna bij de IdP; wissel anders beide kanten tegelijk om op een rustig moment. Test meteen.

Attribuutkoppeling

Attribuutnamen worden meestal exact vergeleken: een LMS dat email verwacht, accepteert Email niet. Controleer ook de identificatie. Een transient NameID verandert bij elke sessie en een e-mailadres kan veranderen; een persistent NameID of een onveranderlijk ID-attribuut is stabiel. Als mensen op e-mailadres worden gekoppeld, archiveer dan het account van een vertrekkende medewerker voordat het adres opnieuw wordt toegewezen.

Niet-passende e-maildomeinen

Directory’s bevatten vaak mensen van wie de inlognaam niet hun e-mailadres is, externen op andere domeinen en medewerkers van overgenomen bedrijven die nog op oude domeinen zitten. Als het LMS accounts tot bepaalde domeinen beperkt, worden zij geweigerd. Zet vóór livegang elk domein op een rij.

Zo doet Acadenix het

SAML-SSO zit in het Gold-abonnement, met stapsgewijze handleidingen voor Entra ID, Okta en Google Workspace.

• Eerst testen, dan activeren. Je slaat de gegevens van je IdP op als concept, voert Test configuration (configuratie testen) uit door in te loggen bij je provider en activeert pas daarna. Een ontbrekende e-mailclaim wordt gemeld met de claimnamen die je provider wel stuurde.
• Gefaseerde wijzigingen. Een nieuw certificaat of een nieuwe tenant komt binnen als configuratie-update en de huidige configuratie blijft werken tot je die activeert.
• JIT binnen je domeinen. Iemand zonder account krijgt bij de eerste aanmelding een cursistaccount, alleen als het e-mailadres op de registratiedomeinen van je organisatie staat, en je kunt dit uitschakelen. Wanneer iemand die al een Acadenix-account heeft voor het eerst via je IdP inlogt, mailt Acadenix een eenmalige code om de koppeling te bevestigen. Dat gebeurt één keer per persoon.
• Twee routes naar binnen. Mensen beginnen op je inlogpagina, die hen rechtstreeks naar je IdP kan sturen of een knop kan tonen, of via de tegel in Mijn apps, Okta of Google.
• Eén koppeling, één organisatie. Een SAML-koppeling wordt niet doorgegeven aan organisaties onder de eigenaar, wat van belang is voor groepen met veel locaties.
• Een noodroute. Als je IdP onbereikbaar is, kunnen beheerders nog steeds inloggen met een eenmalige code per e-mail en dit kan niet worden uitgeschakeld.

Naast SAML kunnen mensen inloggen met een code per e-mail of met een Google-, Microsoft- of LinkedIn-account. Meer daarover op onze beveiligingspagina.

Belangrijkste punten

• Wissel entity ID’s, de ACS URL en metadata uit en koppel dan een stabiele identificatie en een geverifieerd e-mailadres.
• Beperk just-in-time accounts tot je eigen domeinen en de laagste rol.
• Test beide inlogroutes, de weigeringen en de noodroute vóór livegang.
• Zet de vervaldatum van certificaten in je agenda en archiveer LMS-accounts van vertrekkende medewerkers.

Wil je Acadenix koppelen aan je identiteitsprovider? Vergelijk abonnementen op onze prijzenpagina of neem contact met ons op over jouw situatie.