LMS und Single Sign-on: SAML, OIDC, SCIM und Rückschreiben ins HR-System

In Ausschreibungen steht meist ein einzelner Satz: „Das LMS muss Single Sign-on unterstützen.“ Dahinter stecken in Wahrheit drei getrennte Aufgaben mit drei unterschiedlichen Protokollen – und die Verwechslung dieser drei ist die häufigste Ursache dafür, dass ein Projekt in der IT-Abstimmung hängen bleibt.

Dieser Beitrag trennt sie sauber: Anmeldung über SAML 2.0 oder OpenID Connect, Nutzerprovisionierung über SCIM 2.0, und das Rückschreiben von Abschlüssen ins HR-System über API und Webhooks. Dazu die Attribute, die Sie tatsächlich brauchen, und die Besonderheiten bei Personio und HiBob.

Wenn Sie einen allgemeinen Überblick über Anbindungen suchen, ist der Beitrag zur LMS-Integration der richtige Einstieg. Hier geht es um die technische Umsetzung der Identitäts- und HR-Anbindung.

Was leisten Anmeldung, Provisionierung und Rückschreiben – und was nicht?

Diese Abgrenzung ist der wichtigste Abschnitt des Beitrags, weil sie fast alle Folgefragen auflöst:

Single Sign-on allein löst also nur die erste Zeile. Es sorgt dafür, dass sich Mitarbeitende ohne zusätzliches Passwort anmelden – aber es legt keine Konten an, entfernt keine, pflegt keine Abteilungszugehörigkeit und überträgt keine Abschlüsse. Wer nur SSO einrichtet und dann feststellt, dass Pflichtschulungen weiterhin per Hand zugewiesen werden müssen, hat genau diese Grenze übersehen.

Wie funktioniert Single Sign-on über SAML 2.0?

SAML 2.0 ist der etablierte Standard für Single Sign-on in Unternehmensanwendungen. Der Ablauf ist bei allen Identity Providern gleich. Ein Single Sign-on läuft dabei in fünf Schritten ab:

1. Eine Person ruft das LMS auf – dieses ist in der SAML-Sprache der Service Provider.
2. Das LMS leitet den Browser an den Identity Provider weiter, etwa Microsoft Entra ID, Okta oder Keycloak.
3. Dort findet die Anmeldung statt, inklusive Mehr-Faktor-Authentifizierung und etwaiger Zugriffsrichtlinien.
4. Der Identity Provider erzeugt eine signierte Assertion – ein XML-Dokument mit Identität und Attributen – und schickt sie per Browser an die Assertion Consumer Service URL des LMS.
5. Das LMS prüft die Signatur gegen das hinterlegte Zertifikat und startet die Sitzung.

Für die Einrichtung brauchen beide Seiten dieselben vier Angaben: Entity ID von Service Provider und Identity Provider, die ACS-URL, die Single Sign-on-URL des Identity Providers und das X.509-Signaturzertifikat. In der Praxis tauschen die Beteiligten dafür Metadaten-XML-Dateien aus, statt Werte einzeln abzutippen.

Zwei Details, die im Alltag zählen. Erstens der Unterschied zwischen SP-initiiert – der Aufruf beginnt im LMS – und IdP-initiiert, wo der Start über das Portal des Identity Providers erfolgt; für Kachel-Portale ist Letzteres wichtig. Zweitens die Zertifikatslaufzeit: Signaturzertifikate laufen typischerweise nach ein bis drei Jahren ab und sind die klassische Ursache für einen plötzlichen Anmeldeausfall. Der Erneuerungstermin gehört in den Kalender der IT, nicht in die Erinnerung einer einzelnen Person.

Was leisten OAuth 2.0 und OpenID Connect?

Hier liegt das häufigste Missverständnis im ganzen Themenfeld: OAuth 2.0 ist kein Anmeldeverfahren. Es regelt Autorisierung – also die Frage, ob eine Anwendung im Namen einer Person auf bestimmte Ressourcen zugreifen darf. Für die API-Anbindung eines LMS ist das genau richtig, für die Anmeldung von Mitarbeitenden allein nicht ausreichend.

Das Single Sign-on selbst leistet OpenID Connect, kurz OIDC. Es setzt als Identitätsschicht auf OAuth 2.0 auf und liefert zusätzlich ein ID-Token – ein JSON Web Token mit geprüften Angaben zur Person. Der übliche Ablauf ist der Authorization Code Flow, bei modernen Anwendungen mit PKCE als Absicherung.

Praktische Vorteile von OIDC gegenüber SAML:

• Konfiguration über Discovery. Der Identity Provider veröffentlicht seine Endpunkte unter einer Standard-Adresse, üblicherweise /.well-known/openid-configuration. Das ersetzt den manuellen Metadatenabgleich.
• JSON statt XML. Kleinere Nutzlast, weniger Fehleranfälligkeit bei Signaturen und Umbrüchen.
• Bessere Eignung für Apps. Für mobile Anwendungen und Single-Page-Anwendungen ist OIDC der vorgesehene Weg; SAML ist auf browserbasierte Weiterleitungen ausgelegt.
• Scopes und Claims. Über Scopes wie openid, profile und email steuern Sie, welche Angaben übermittelt werden – Datenminimierung wird damit konfigurierbar.

Die gängigen Identity Provider beherrschen beides. Google Workspace etwa unterstützt sowohl SAML als auch OIDC und erlaubt es, verschiedene Profile einzelnen Organisationseinheiten zuzuweisen – nützlich, um Single Sign-on zunächst mit einer Testgruppe zu erproben.

SAML oder OIDC: Was sollten Sie wählen?

Die pragmatische Regel für das Single Sign-on: Nehmen Sie das Protokoll, das Ihr Identity Provider bereits für andere Anwendungen nutzt. Wer Microsoft 365 im Einsatz hat, fährt mit Entra ID gut und kann beide Wege gehen. Ein Protokollwechsel nur für das LMS erzeugt Aufwand ohne Gegenwert. Und in beiden Fällen gilt die letzte Zeile der Tabelle: Die Nutzerverwaltung ist damit noch nicht gelöst.

Wie funktioniert Nutzerprovisionierung über SCIM 2.0?

SCIM 2.0 ist ein REST-basierter Standard, mit dem der Identity Provider Nutzerkonten im Zielsystem aktiv verwaltet. Das LMS stellt dafür eine Basis-URL und ein Zugriffstoken bereit, der Identity Provider sendet daraufhin Änderungen:

• Anlegen: POST /Users, sobald eine Person im Verzeichnis dem LMS zugewiesen wird
• Aktualisieren: PATCH /Users/{id} bei Änderung von Abteilung, Nachname, Standort oder Vorgesetzten
• Deaktivieren: PATCH mit active: false beim Austritt – meist besser als Löschen, weil Nachweise erhalten bleiben müssen
• Gruppen: POST und PATCH auf /Groups, damit Abteilungs- oder Rollengruppen im LMS für Kurszuweisungen nutzbar sind

Der entscheidende Vorteil gegenüber reinem Single Sign-on liegt im Zeitpunkt. Weil das Konto entsteht, sobald die Person im Verzeichnis erfasst ist, lassen sich Pflichtschulungen vor dem ersten Login zuweisen – mit Frist, Erinnerung und Nachweis. Genau das ist bei Onboarding-Prozessen und Compliance-Nachweisen der Punkt, an dem sich die Investition rechnet.

Ebenso wichtig ist die Gegenrichtung: Beim Austritt wird das Konto automatisch deaktiviert. Ohne diesen Mechanismus sammeln sich aktive Konten ausgeschiedener Personen – ein Befund, der in jeder Prüfung auffällt und die Kennzahlen zur Abschlussquote dauerhaft verzerrt.

Die reteach Lernplattform nutzt für diesen Zweck eine Schnittstelle nach dem SCIM-2.0-Standard, dokumentiert für Microsoft Entra ID und dadurch auch mit anderen Verzeichnisdiensten nutzbar. Empfohlen wird die Kombination aus Synchronisation und Single Sign-on, damit Kontoanlage und Anmeldung zusammenpassen.

Wann reicht Just-in-Time-Provisionierung?

Bei der Just-in-Time-Provisionierung entsteht das Konto im Moment der ersten Anmeldung per Single Sign-on – aus den Attributen, die SAML oder OIDC mitliefern. Kein SCIM, keine zusätzliche Konfiguration.

Das genügt, wenn drei Bedingungen zutreffen: Die Nutzung ist freiwillig, es gibt keine Zuweisung mit Frist vor dem ersten Login, und der Personalwechsel ist überschaubar oder wird anderweitig kontrolliert.

Für Pflichtschulungen ist Just-in-Time dagegen ungeeignet, und zwar aus einem strukturellen Grund: Sie können keine Schulung an eine Person zuweisen, die im System noch nicht existiert. Damit lässt sich vor dem ersten Login weder eine Frist setzen noch eine Erinnerung versenden noch eine Abdeckungsquote berechnen. Und da beim Austritt keine Rückmeldung erfolgt, bleiben Konten aktiv.

Welche Attribute sollten Sie übertragen?

Beim Single Sign-on und bei der Provisionierung gilt: Weniger ist mehr – aber die richtigen Felder müssen dabei sein:

Zwei Regeln sparen später Aufräumarbeit. Erstens: Die unveränderliche ID ist der Schlüssel. Wer die E-Mail-Adresse verwendet, erzeugt bei jeder Namensänderung ein zweites Konto – und verliert die Nachweishistorie der Person. Zweitens: Nur Felder übertragen, die im LMS eine Funktion haben. Jedes zusätzliche personenbezogene Feld muss im Verarbeitungsverzeichnis begründet werden und erhöht ohne Nutzen die Angriffsfläche.

Wie schreiben Sie Abschlüsse ins HR-System zurück?

Das ist die Anforderung, die in Auswahlprozessen am häufigsten unterschätzt wird – und die den Unterschied zwischen einer Lernplattform als Insel und als integriertem Baustein macht. Drei Muster stehen zur Verfügung:

Der Webhook-Weg ist der sauberste: Sobald eine Person einen Kurs abschließt, geht ein Datensatz an das Zielsystem – mit Personenkennung, Kursbezeichnung, Version, Abschlusszeitpunkt und Ergebnis. Die reteach Lernplattform bietet dafür eine offene REST-API in Kombination mit Webhooks; die API-Dokumentation ist öffentlich zugänglich, sodass die IT Endpunkte und Authentifizierung vorab prüfen kann.

Vier Punkte, die in der Umsetzung über Stabilität entscheiden:

• Zuordnungstabelle statt Namensabgleich. Die Personenkennung des LMS muss auf die Kennung im HR-System abgebildet werden. Ein Abgleich über Namen oder E-Mail-Adressen scheitert zuverlässig.
• Idempotenz. Derselbe Abschluss darf mehrfach ankommen, ohne doppelte Einträge zu erzeugen. Eine eindeutige Ereignis-ID löst das.
• Wiederholungslogik und Fehlerbehandlung. Wenn das HR-System kurz nicht antwortet, muss der Versand erneut versucht und im Fehlerfall protokolliert werden – sonst fehlt genau der Nachweis, den niemand vermisst, bis er gebraucht wird.
• Datenminimierung. Ins HR-System gehören Abschluss, Datum und Kursbezeichnung. Bearbeitungsdauer, Anzahl der Versuche oder Einzelantworten gehören dort nicht hin.

Beim letzten Punkt geht es nicht nur um Datenschutz. Sobald Schulungsdaten in die Personalakte fließen, kann eine technische Einrichtung zur Leistungs- und Verhaltenskontrolle vorliegen – und die ist in Betrieben mit Betriebsrat mitbestimmungspflichtig. Klären Sie das Vorhaben früh, nicht nach der technischen Umsetzung.

Was gilt speziell für Personio und HiBob?

Beide Systeme sind im Mittelstand verbreitet, unterscheiden sich aber im Anbindungsmuster.

Personio stellt einen öffentlichen API-Zugang samt Developer Hub und Webhooks bereit; Zugangsdaten werden im Konto erzeugt und mit Berechtigungen versehen. Für die automatisierte Bereitstellung von Nutzerkonten setzt Personio nach derzeitigem Stand auf die eigene REST-API beziehungsweise einen Connector für Entra ID – einen nativen SCIM-2.0-Endpunkt bietet die Plattform nicht. Praktisch bedeutet das: Personio dient als Datenquelle für Personalstammdaten, während die Kontoverwaltung im LMS in der Regel über den Verzeichnisdienst läuft.

Für das Rückschreiben von Abschlüssen sind zwei Wege üblich: die Ablage im Schulungs- beziehungsweise Weiterbildungsbereich des HR-Systems oder – wenn dieser die benötigten Felder nicht abdeckt – ein benutzerdefiniertes Attribut am Personendatensatz. Wichtig zu wissen: Die Schlüssel benutzerdefinierter Attribute sind unternehmensspezifisch und müssen vor der Entwicklung bekannt sein. Wer Zertifikate als Nachweis benötigt, kann zusätzlich die PDF-Datei am Personendatensatz ablegen. Einen Einstieg für das Entwicklungsteam liefert der Personio Developer Hub.

HiBob verfolgt einen ähnlichen Ansatz mit dokumentierter API, Berechtigungsbereichen pro Zugriffstoken und der Möglichkeit, eigene Felder und Tabellen anzulegen. Auch hier gilt: Zielfeld und Berechtigungen vor der Umsetzung festlegen.

Unabhängig vom System sollten drei Fragen vor dem ersten Entwicklungsschritt geklärt sein: In welches Feld wird geschrieben? Welche Berechtigungen braucht das Zugriffstoken – und nur diese? Und wer prüft, dass die Daten ankommen, wenn die Person, die es eingerichtet hat, im Urlaub ist?

Wie gehen Sie bei der Einrichtung vor?

Schritt 8 wird am häufigsten übersprungen und verursacht die meisten späteren Störungen. Ein abgelaufenes Signaturzertifikat oder ein ausgelaufenes Zugriffstoken legt die Anmeldung beziehungsweise die Synchronisation ohne Vorwarnung still. Beide Termine gehören dokumentiert und überwacht.

Für den Aufbau des Systems selbst finden Sie die praktischen Schritte im Beitrag zum LMS einführen; beim Wechsel von einer bestehenden Plattform hilft der Leitfaden zur LMS-Migration.

Welche Fehler treten am häufigsten auf?

• SSO mit Provisionierung verwechseln. Der Klassiker: Single Sign-on ist eingerichtet, aber Pflichtschulungen müssen weiterhin manuell zugewiesen werden.
• E-Mail als Schlüssel verwenden. Führt bei jeder Namensänderung zu Doppelkonten und zerstörter Nachweishistorie.
• Abteilungswerte nicht abstimmen. Freitextfelder aus dem Verzeichnis erzeugen Dutzende Varianten derselben Abteilung – automatische Zuweisungsregeln greifen dann nicht.
• Zertifikats- und Tokenlaufzeiten ignorieren. Ein Ausfall ohne Vorwarnung, der sich mit einem Kalendereintrag vermeiden lässt.
• Zu viele Attribute übertragen. Jedes zusätzliche Feld ist zu begründen und erhöht das Risiko ohne Nutzen.
• Ohne Testgruppe live gehen. Falsch konfigurierte Weiterleitungen sperren im Ernstfall die gesamte Belegschaft aus.
• Kein Notfallzugang. Fällt der Identity Provider aus, muss mindestens ein administratives Konto ohne Single Sign-on anmelden können.
• Mitbestimmung zu spät klären. Beim Rückschreiben von Schulungsdaten in die Personalakte verschiebt eine späte Klärung den Projektabschluss um Wochen.

Fazit und nächste Schritte

Single Sign-on ist die Anmeldung – nicht mehr. Wer eine Lernplattform wirklich in die Systemlandschaft einbinden will, braucht drei Bausteine: SAML 2.0 oder OpenID Connect für die Authentifizierung, SCIM 2.0 für die automatische Bereitstellung und Deaktivierung von Konten, sowie API und Webhooks für den Rückfluss der Abschlüsse ins HR-System.

Der Baustein mit dem größten praktischen Effekt ist die Provisionierung. Sie entscheidet darüber, ob sich Pflichtschulungen vor dem ersten Login zuweisen lassen und ob ausgeschiedene Personen automatisch verschwinden – beides Voraussetzungen für belastbare Nachweise.

Ihre nächsten drei Schritte:

1. Klären, welcher Identity Provider im Einsatz ist und welches Protokoll andere Anwendungen dort nutzen – das entscheidet die Protokollfrage bereits.
2. Die Attributliste mit HR und IT gemeinsam festlegen, inklusive Schlüsselattribut und abgestimmter Wertebereiche für Abteilung und Standort.
3. Vor dem ersten Entwicklungsschritt definieren, in welches Feld des HR-Systems die Abschlüsse geschrieben werden – und die Mitbestimmung dazu anstoßen.

Die reteach Lernplattform ist DSGVO-konform, wird in Deutschland gehostet und bringt die drei Bausteine mit: Synchronisation von Teilnehmenden und Gruppen über SCIM 2.0, Anmeldung per Single Sign-on sowie eine offene REST-API mit Webhooks für Abschlüsse und Zertifikate. Fertige Anbindungen an gängige HR-, Kommunikations- und Verzeichnisdienste – darunter Personio – ergänzen individuelle Integrationen über die dokumentierte Schnittstelle.

Häufig gestellte Fragen