Jedes separate Login ist ein weiteres Passwort, das zurückgesetzt werden muss, und ein weiteres Konto, das geschlossen werden muss, wenn jemand geht. SAML-Single-Sign-on (SSO) verbindet Ihr Lernmanagementsystem mit Ihrem Identity Provider: Personen melden sich mit ihrem Arbeitskonto zur Schulung an, und der Zugriff folgt Ihrem Verzeichnis. Hier erfahren Sie, wie SAML funktioniert, wie die Einrichtung mit Microsoft Entra ID, Okta oder Google Workspace abläuft und was Sie vor dem Livegang prüfen sollten.
So funktioniert SAML-Single-Sign-on
SAML (Security Assertion Markup Language) 2.0 ist ein offener Standard, um Anmeldeinformationen zwischen zwei Systemen auszutauschen, die einander vertrauen. Das LMS sieht das Passwort der Person nie: Es leitet sie zu Ihrem Identity Provider weiter, der prüft, wer sie ist – mit jeder Multi-Faktor-Authentifizierung, die Sie verlangen –, und sie mit einer signierten Aussage zurückschickt.
| Begriff | Bedeutung |
|---|---|
| Identity Provider (IdP) | Das System, das Ihre Mitarbeitenden authentifiziert, etwa Entra ID, Okta oder Google Workspace. |
| Service Provider (SP) | Die Anwendung, bei der sich Personen anmelden: Ihr LMS. |
| Assertion | Die signierte XML-Aussage des IdP: wer die Person ist, wann sie sich angemeldet hat und Attribute wie E-Mail-Adresse und Name. |
| Entity ID | Ein eindeutiger Name für jede Seite, oft wie eine URL aufgebaut, aber nur ein Bezeichner. Er muss exakt übereinstimmen. |
| ACS URL | Die Assertion Consumer Service URL: die LMS-Adresse, die die Antwort des IdP entgegennimmt. |
| Signaturzertifikat | Der IdP signiert mit seinem privaten Schlüssel; das LMS prüft mit dem öffentlichen Zertifikat des IdP und weist gefälschte oder veränderte Assertions zurück. |
| Metadaten | Eine XML-Datei, die Entity ID, Endpunkte und Zertifikate bündelt und sich direkt importieren lässt. |
Assertions sind kurzlebig und nennen ihre Zielgruppe (die Entity ID des SP). Der SP weist alles zurück, was abgelaufen oder für eine andere Anwendung bestimmt ist.
Warum sich SSO für ein LMS lohnt
- Keine zusätzlichen Passwörter. Personen nutzen ihr alltägliches Konto, und Ihre MFA und Zugriffsrichtlinien gelten auch für die Schulung.
- Neue Mitarbeitende erhalten schnell Zugriff. Weisen Sie die LMS-Anwendung einer Gruppe zu, und neue Beschäftigte darin können sich am ersten Tag anmelden.
- Ausscheidende verlieren den Zugriff an der Quelle. Deaktivieren Sie jemanden in Ihrem Verzeichnis, kann die Person keine neue LMS-Sitzung mehr starten. SAML steuert die Anmeldung, nicht das Konto – archivieren Sie das LMS-Konto daher auch als Teil des Offboardings.
Kontoerstellung Just-in-time
Bei der Just-in-time-Provisionierung (JIT) legt das LMS beim ersten Anmelden einer Person ein Konto aus den Attributen der Assertion an, sodass keine Nutzerliste importiert werden muss. Setzen Sie dafür Leitplanken:
- Beschränken Sie sie auf Ihre eigenen E-Mail-Domains, damit eine falsch konfigurierte Anwendung oder ein Gastkonto keine überflüssigen Nutzer anlegt.
- Geben Sie neuen Konten die niedrigste Rolle und vergeben Sie Administratorrechte gezielt.
- Ordnen Sie Personen anhand einer stabilen Kennung zu, wenn Ihr IdP eine senden kann, denn E-Mail-Adressen ändern sich.
SP-initiierte vs. IdP-initiierte Anmeldung
- SP-initiiert: Die Person öffnet das LMS, das eine Authentifizierungsanfrage an den IdP sendet, und der IdP schickt seine Antwort per POST an die ACS URL. Das funktioniert über Lesezeichen und E-Mail-Links und gilt allgemein als der sicherere Ablauf, weil die Antwort auf eine Anfrage des LMS reagiert.
- IdP-initiiert: Die Person klickt auf die Kachel der Anwendung in Microsoft My Apps, in ihrem Okta-Dashboard oder im Google-Apps-Menü, und der IdP sendet eine nicht angeforderte Antwort an die ACS URL.
Sie können beide anbieten; testen Sie jeden Ablauf.
SAML-SSO einrichten, Schritt für Schritt
Der Ablauf ist überall ziemlich ähnlich:
- Umfang planen: Wer nutzt SSO, welche Gruppen erhalten die Anwendung, welche E-Mail-Domains sind erlaubt, und welches Attribut identifiziert jede Person.
- Die Verbindung im LMS anlegen und sich Entity ID und ACS URL notieren.
- Eine SAML-Anwendung bei Ihrem IdP anlegen – mit diesen Werten –, das NameID-Format wählen und Attribute für E-Mail-Adresse, Vor- und Nachname ergänzen.
- Nutzer oder Gruppen zuweisen; nicht zugewiesene Personen werden meist abgewiesen.
- Dem LMS die IdP-Angaben geben: eine Metadaten-URL, eine Metadatendatei oder Entity ID, Anmelde-URL und Signaturzertifikat des IdP.
- Die Attribute zuordnen – auf die Namen, die Ihr IdP tatsächlich sendet.
- Testen, dann einschalten – und den Personen mitteilen, was sich ändert.
Hinweise zu den Anbietern
Die Dokumentation Ihres Anbieters zeigt die genauen Bildschirme. Gut zu wissen:
- Microsoft Entra ID: Verwenden Sie eine Enterprise-Anwendung außerhalb des Katalogs (Non-Gallery), keine App-Registrierung – diese bietet kein SAML. Claim-Namen sind lange URIs, kopieren Sie sie daher exakt. Die Objekt-ID eignet sich gut als stabile Kennung. Bei Personen ohne Postfach kann der E-Mail-Claim leer sein; der Benutzerprinzipalname kann einspringen, wenn er eine echte Adresse ist.
- Okta: Legen Sie eine SAML-2.0-App-Integration an. Die Attribute Statements benennen Sie selbst, sie müssen daher exakt – einschließlich Groß- und Kleinschreibung – zur Zuordnung im LMS passen. Die interne Nutzer-ID von Okta eignet sich als stabile Kennung.
- Google Workspace: Fügen Sie eine benutzerdefinierte SAML-App hinzu und laden Sie deren Metadatendatei herunter. Die App ist zunächst ausgeschaltet; schalten Sie sie für die richtigen Organisationseinheiten oder Gruppen ein. Üblicherweise werden Personen über die primäre E-Mail-Adresse identifiziert – planen Sie daher für umbenannte und wiederverwendete Adressen.
Testcheckliste
Prüfen Sie vor dem Livegang Folgendes in einem privaten Browserfenster:
- Ein bestehender Nutzer meldet sich ausgehend vom LMS an und noch einmal über die App-Kachel.
- Ein neuer Nutzer aus Ihrer Domain erhält ein Konto mit der richtigen Rolle.
- Jemand, der der Anwendung nicht zugewiesen ist, wird abgewiesen.
- Jemand außerhalb Ihrer erlaubten Domains wird abgewiesen.
- E-Mail-Adresse, Vor- und Nachname kommen korrekt an.
- Ein Administrator kommt weiterhin über den Wiederherstellungsweg hinein.
Häufige Stolperfallen
Zeitabweichung (Clock Skew)
Weichen die Uhren von IdP und LMS um mehr ab, als das LMS toleriert, werden gültige Assertions als noch nicht gültig oder bereits abgelaufen abgelehnt. Das betrifft vor allem selbst gehostete Identitätsserver; halten Sie deren Uhren daher synchron.
Zertifikatswechsel
Signaturzertifikate von IdPs laufen ab, und wenn das LMS dem neuen nicht vertraut, schlägt jede Anmeldung auf einmal fehl. Tragen Sie das Ablaufdatum in Ihren Kalender ein. Kann Ihr LMS zwei Zertifikaten vertrauen, fügen Sie dort zuerst das neue hinzu und aktivieren es dann beim IdP; andernfalls stellen Sie beide Seiten gemeinsam zu einer ruhigen Zeit um. Testen Sie sofort.
Attributzuordnung
Attributnamen werden in der Regel exakt abgeglichen: Ein LMS, das email erwartet, akzeptiert Email nicht. Prüfen Sie auch die Kennung. Eine transiente NameID ändert sich mit jeder Sitzung, und eine E-Mail-Adresse kann sich ändern; eine persistente NameID oder ein unveränderliches ID-Attribut ist stabil. Werden Personen über die E-Mail-Adresse zugeordnet, archivieren Sie das Konto einer ausgeschiedenen Person, bevor ihre Adresse neu vergeben wird.
Abweichende E-Mail-Domain
Verzeichnisse enthalten oft Personen, deren Anmeldename nicht ihre E-Mail-Adresse ist, externe Auftragnehmer mit anderen Domains und Beschäftigte übernommener Unternehmen, die noch auf alten Domains sind. Beschränkt das LMS Konten auf bestimmte Domains, werden sie abgewiesen. Listen Sie vor dem Livegang jede Domain auf.
So macht es Acadenix
SAML-SSO gibt es im Gold-Tarif, mit Schritt-für-Schritt-Anleitungen für Entra ID, Okta und Google Workspace.
- Testen, dann aktivieren. Sie speichern die IdP-Angaben als Entwurf, führen Test configuration (Konfiguration testen) aus, indem Sie sich bei Ihrem Anbieter anmelden, und aktivieren erst danach. Ein fehlender E-Mail-Claim wird zusammen mit den Claim-Namen gemeldet, die Ihr Anbieter tatsächlich gesendet hat.
- Gestufte Änderungen. Ein neues Zertifikat oder ein neuer Tenant wird als Konfigurationsaktualisierung eingespielt, und die aktuelle Konfiguration funktioniert weiter, bis Sie die neue aktivieren.
- JIT innerhalb Ihrer Domains. Wer kein Konto hat, erhält bei der ersten Anmeldung ein Lernendenkonto – nur wenn die E-Mail-Adresse zu den Registrierungsdomains Ihrer Organisation gehört –, und Sie können das abschalten. Meldet sich jemand, der bereits ein Acadenix-Konto hat, erstmals über Ihren IdP an, sendet Acadenix der Person per E-Mail einen Einmalcode, um die Verknüpfung zu bestätigen. Das geschieht einmal pro Person.
- Beide Wege hinein. Personen beginnen auf Ihrer Anmeldeseite, die sie direkt zu Ihrem IdP weiterleiten oder eine Schaltfläche anzeigen kann, oder über die Kachel in My Apps, Okta oder Google.
- Eine Verbindung, eine Organisation. Eine SAML-Verbindung wird nicht an Organisationen unterhalb ihres Eigentümers vererbt, was für Gruppen mit vielen Standorten wichtig ist.
- Ein Wiederherstellungsweg. Fällt Ihr IdP aus, können sich Administratoren weiterhin mit einem per E-Mail gesendeten Einmalcode anmelden – und dieser Weg lässt sich nicht abschalten.
Neben SAML können sich Personen mit einem per E-Mail gesendeten Code oder mit einem Google-, Microsoft- oder LinkedIn-Konto anmelden. Mehr dazu auf unserer Sicherheitsseite.
Das Wichtigste in Kürze
- Tauschen Sie Entity IDs, ACS URL und Metadaten aus und ordnen Sie dann eine stabile Kennung und eine verifizierte E-Mail-Adresse zu.
- Beschränken Sie Just-in-time-Konten auf Ihre eigenen Domains und die niedrigste Rolle.
- Testen Sie vor dem Livegang beide Anmeldeabläufe, die Abweisungen und den Wiederherstellungsweg.
- Tragen Sie das Ablaufdatum von Zertifikaten in Ihren Kalender ein und archivieren Sie die LMS-Konten Ausgeschiedener.
Möchten Sie Acadenix mit Ihrem Identity Provider verbinden? Vergleichen Sie die Tarife auf unserer Preisseite oder sprechen Sie mit uns über Ihr Setup.
