Alles auf eine Karte

von Dr. Matthias Wübbeling

Konten anlegen, Passwörter zurücksetzen, beim Offboarding Zugänge vergessen – der manuelle Verwaltungsaufwand verteilter Benutzerverwaltungen kostet Zeit und erzeugt Sicherheitsrisiken. Zentrale Authentifizierung per OIDC oder SAML, kombiniert mit automatisiertem Provisioning über SCIM, macht Identity-Management beherrschbar.

In vielen Unternehmen wächst die Sammlung an Collaboration-Werkzeugen über Jahre hinweg, meist recht organisch und bedarfsorientiert. Während Ihre Entwicklungsabteilung mit GitLab arbeitet, setzt Ihr Projektmanagement auf Confluence, beliebige Dateien landen für die Kooperation mit den Kollegen in der selbst gehosteten Nextcloud-Instanz und für E-Mail oder Office-Anwendungen kommt Microsoft 365 zum Einsatz. Jede dieser Plattformen wird dabei vielleicht sogar von einem anderen Teil der IT-Abteilung betreut und bringt natürlich auch ihre eigene Benutzerverwaltung, eigene Passwortregeln und oft auch eigene Mechanismen für die weitere Accountabsicherung mit, etwa über Multifaktor-Authentifizierung.

Was in kleinen Infrastrukturen zunächst praktikabel erscheint, entwickelt sich mit zunehmender Zahl an Anwendungen aber schnell zu einem administrativen Problem des gesamten Unternehmens. Benutzerkonten für Mitarbeiter müssen dann mehrfach angelegt und gepflegt werden, die effektiven Rollen der Mitarbeiter unterscheiden sich zwischen den Plattformen und deaktivierte Konten ausgeschiedener Mitarbeiter bleiben in einzelnen Systemen noch lange aktiv. Denn während das Onboarding durch neue Mitarbeiter selbst vorangetrieben wird, entstehen gerade beim Offboarding regelmäßig Sicherheits- und Compliancerisiken.

Wenn Sie in Ihrem Unternehmen für die Benutzerverwaltung verantwortlich sind, kennen Sie das Problem längst. Wächst die Zahl der vorhandenen Anwendungen, steigt auch der Aufwand, für Benutzer und Administratoren gleichermaßen. Anwender jonglieren mit unterschiedlichen Kennwörtern und Anmeldemasken, während Sie im IT-Support Anfragen zu vergessenen Passwörtern, gesperrten Konten oder inkonsistenten Berechtigungen bearbeiten müssen.

Single-Sign-on-Lösungen (SSO) gibt es seit vielen Jahren. Diese adressieren die genannten Probleme zumindest zum Großteil. Statt Benutzerkonten separat in jeder Anwendung zu verwalten, erfolgt die Authentifizierung zentral über einen Identity Provider. Die laufenden Anwendungen vertrauen diesem zentralen Dienst und übernehmen damit Benutzeridentitäten, Gruppeninformationen und Rollen, bestenfalls automatisiert. Für Anwender bedeutet das konkret, dass nur noch ein Login für mehrere Anwendungen notwendig ist. Für Sie als Verantwortlichen entsteht durch den SSO-Einsatz eine besser kontrollierbare Umgebung mit zentral durchsetzbaren Sicherheitseinstellungen, wie MFA, konsistenten Richtlinien und managebarem Account-Lebenszyklus.

Die Technologien dahinter heißen OpenID Connect, SAML 2.0 und SCIM. Diese ermöglichen es, sowohl Enterprise-Anwendungen, die as-a-Service vom Unternehmen eingekauft werden, als auch selbst gehostete Open-Source-Anwendungen in ein gemeinsames Authentifizierungs- und Provisioning-Konzept einzubinden.

Mehr als nur ein gemeinsamer Login

Der Einsatz von SSO wird im Unternehmensalltag häufig auf die reine Anmeldung reduziert. In der Theorie melden sich Benutzer morgens einmal an und erhalten anschließend Zugriff auf alle (oder zumindest die wichtigen) Anwendungen. Tatsächlich steckt heute hinter SSO-Umgebungen jedoch deutlich mehr als nur ein gemeinsamer Login.

Im Zentrum steht dabei der Identity Provider (IdP). Er übernimmt die Authentifizierung der Benutzer und stellt deren Identitätsdetails allen angebundenen Anwendungen zur Verfügung. Die eigentlichen Applikationen vertrauen dem Identity Provider und verzichten auf eine eigene Benutzeranmeldung. Wir betrachten im Folgenden GitLab als Beispielplattform, dieselben Einstellungen lassen sich aber auch in Confluence oder Nextcloud konfigurieren.

Das zentrale Login-Element allein löst leider viele Probleme in Ihrem Unternehmensalltag noch nicht. Entscheidend kommt nämlich hinzu, dass Sicherheitsrichtlinien und Benutzerverwaltung ebenfalls zentral gesteuert werden müssten. Dazu gehört im ersten Schritt die Multifaktor-Authentifizierung (MFA). Statt diese in jeder Anwendung separat zu konfigurieren, erzwingen moderne IdPs zusätzliche Faktoren zentral, etwa per TOTP-App wie dem Authenticator, Pushbestätigung über spezialisierte Apps oder dem auch FIDO2 zugrundeliegenden WebAuthn-Protokoll. Die angebundenen Anwendungen profitieren automatisch von diesen Richtlinien, ohne selbst MFA-Mechanismen implementieren zu müssen.

Ebenso wichtig ist die automatisierte Benutzerverwaltung. Genau hier kommt das "System for Cross-Domain Identity Management" (SCIM) ins Spiel. Während SSO die Anmeldung an sich regelt, kümmert sich SCIM um das Provisioning von Benutzern und Gruppen. So werden neue Mitarbeiter automatisch in den angebundenen Plattformen angelegt, ihre Rollen synchronisiert und die verteilten Konten beim Offboarding zuverlässig deaktiviert. Gerade in größeren Umgebungen reduziert SCIM den manuellen Verwaltungsaufwand für die IT-Abteilung deutlich.

Benutzergruppen aus dem IdP sollten sich bestenfalls direkt auf Rollen in den Anwendungen abbilden lassen. So erhalten neue Entwickler im Team automatisch Zugriff auf die relevanten Repositorys in GitLab, während die Mitarbeiter der Projektteams passende Berechtigungen in Confluence erhalten.

Nicht zuletzt entscheidet ein sauberes Session-Management über die Sicherstellung von Aspekten der IT-Sicherheit einer SSO-Umgebung. Melden Sie einen Benutzer zentral ab oder deaktivieren Sie das Konto eines ausgeschiedenen Kollegen, sollten aktive Sitzungen in den angebundenen Anwendungen bestenfalls direkt beendet werden.

OIDC: Moderner Standard für Anwendungsanbindung

Steht die Entscheidung für einen zentralen Identity Provider erst einmal, folgt schnell die nächste Diskussion über den Standard, mit dem die Anwendungen angebunden werden sollen.

Eigentlich alle modernen Anwendungen unterstützen OIDC inzwischen direkt, was die Anbindung an den IdP deutlich erleichtert. Aus Ihrer Sicht spricht also vor allem die vergleichsweise unkomplizierte Integration für OIDC. Anwendungen benötigen meist nur wenige zentrale Angaben für die erfolgreiche Konfiguration.

Dazu gehört die sogenannte Client-ID, also die Kennung der Anwendung im System des Identity Providers. Dieser erkennt damit, welche Anwendung eine Anmeldung anfordert. Zusätzlich wird ein dazu passendes Secret erwartet, was im Grunde das Kennwort der Applikation selbst ist. Das Programm autorisiert sich damit, um Authentifizierungsanfragen an den IdP zu stellen. Dieses Secret muss daher natürlich vertraulich behandelt werden.

Bei der dritten Angabe handelt es sich um die Redirect-URI. Sie definiert, an welche Webadresse der Benutzer nach einem erfolgreichen Login beim IdP zurückgeleitet wird. Genau an dieser Stelle entstehen immer wieder Fehler, weil bereits kleine Abweichungen bei Hostnamen, Pfaden oder HTTPS-Konfigurationen dazu führen können, dass Anmeldungen an der Anwendung scheitern. Arbeiten Sie etwa mit Reverse-Proxys oder mehreren unterschiedlichen Subdomains, sollten Sie die Redirect-URIs deshalb bei der Suche nach Fehlerursachen besonders im Blick haben.

Abgeschlossen wird die Konfiguration durch die URL des Endpunkts beim IdP. Darüber findet die Anwendung die notwendigen Informationen zur Anmeldung, Token-Ausstellung und Benutzeridentität. Moderne Identity-Plattformen stellen diese Informationen meist automatisch über standardisierte Discovery-URLs bereit.

Ein großer Vorteil von OIDC liegt darin, dass sich Benutzerattribute mittels JSON Web Token (JWT) direkt an die Zielapplikation übertragen lassen. Neben Benutzername oder E-Mail-Adresse können so beispielsweise auch Gruppen- oder Rolleninformationen zentral übergeben werden. Anwendungen können Benutzer dadurch automatisch den passenden Berechtigungen zuordnen, ohne dass Sie die Rollen lokal nachpflegen müssen.

SAML 2.0: Bewährtes Protokoll mit Tücken

Während moderne Anwendungen heute öfter OpenID Connect verwenden, begegnet Ihnen in gewachsenen Unternehmensumgebungen weiterhin oft SAML 2.0. SAML steht für "Security Assertion Markup Language" und liegt heute vor allem der Authentifikation und Autorisierung bei etablierten Business-Anwendungen, älteren SaaS-Plattformen und klassischer Enterprise-Software zugrunde. Auch Programme wie Confluence oder andere interne Unternehmensportale werden häufig noch per SAML angebunden.

Das Grundprinzip ähnelt dabei OIDC, das bedeutet, dass Sie die eigentliche Anmeldung über einen zentralen Identity Provider abwickeln. Die Anwendung selbst vertraut dann auf dessen Bestätigung, dass ein Benutzer erfolgreich authentifiziert wurde. In der Praxis ist der Ablauf aber etwas komplizierter. Nach erfolgreicher Anmeldung erzeugt der IdP eine sogenannte SAML-Assertion. Dabei handelt es sich vereinfacht gesagt um ein signiertes XML-Dokument, ähnlich dem JWT, das Aussagen (sogenannte Statements) über den gerade angemeldeten Benutzer und entsprechende Rechte beim Zugriff auf Ressourcen enthält. Also alle relevanten Informationen vom Benutzernamen über die E-Mail-Adresse bis hin zu Gruppenmitgliedschaften und Rolleninformationen.

Die Applikation überprüft nun die Signatur dieser Assertion und die Integrität der XML-Daten. Das geschieht mit kryptografischen Verfahren auf Basis von Schlüsselpaaren und Zertifikaten.

Bei der Vorbereitung und Konfiguration einer Anwendung für die Benutzung von SAML müssen Sie diese Zertifikate erstellen und austauschen, die Signatureinstellungen korrekt konfigurieren und natürlich über die gesamte Zeit den Lebenszyklus der Zertifikate im Auge behalten. Kleine Fehler in der Abstimmung wirken sich auch hier mitunter direkt auf den Login-Prozess aus. Schon kleine Zeitabweichungen zwischen Servern oder abgelaufene Zertifikate können dazu führen, dass Anmeldungen fehlschlagen.

Trotz dieser etwas höheren Komplexität besitzt SAML weiterhin einen festen Platz im Unternehmensalltag. Viele bestehende Programme werden über Jahre hinweg stabil mit SAML betrieben. Gerade in größeren IT-Infrastrukturen ist es deshalb völlig normal, sowohl OIDC-Anwendungen als auch SAML-Integrationen zusammen zu betreiben.

Authentik als self-hosted Identity Provider

Wenn Sie den Einstieg in SSO und zentrale Identity Provider planen, oder das Thema einfach mal hands-on ausprobieren möchten, macht Ihnen Au- thentik das Leben bemerkenswert leicht. Authentik kombiniert neben OIDC-, SAML- und SCIM-Unterstützung noch viele weitere Protokolle und die Verwaltung in einer vergleichsweise übersichtlichen Administrationsoberfläche. Authentik eignet sich sowohl für kleinere Umgebungen als auch für komplexere Infrastrukturen.

In einer typischen IT-Infrastruktur übernimmt Authentik dann die Rolle des IdP und stellt die SSO-Funktionalität bereit. Bevor Sie mit Authentik loslegen, bietet es sich an, zunächst ein paar hausmeisterliche Aufgaben zu erledigen. Dazu gehören etwa die konsistente DNS-Konfiguration, vollständig mit HTTPs gesicherten Anwendungen, eine funktionierende Zeitsynchronisation auf den beteiligten Servern und saubere Header im Reverse-Proxy, etwa, wenn Sie Ihre Dienste als Docker-Container laufen lassen. Gerade Zeitabweichungen zwischen Systemen führen bei SSO-Anwendungen zu schwer nachvollziehbaren Problemen.

Die Authentik-Entwickler bieten eine gute Dokumentation für das Setup, etwa mit Docker Compose [1]. Nach dem Aufsetzen melden Sie sich an Authentik an und wählen im Menü den Punkt "Applications". Klicken Sie nun auf den Button "Mit Provider erstellen" und legen einen neuen Provider vom Typ OpenID Connect an, Bild 1 zeigt Ihnen die verfügbaren Protokolle in diesem Dialog. Dabei erzeugt Authentik direkt eine Client-ID und ein Secret für die Applikation. Zusätzlich legt es einen sogenannten Slug an, das ist ein Teil der URL, mit der Authentik die Anwendung am Ende identifiziert. Hinterlegen Sie in dem Dialog auch die oben bereits erwähnte Redirect-URI der Anwendung. Für GitLab lautet diese Adresse typischerweise "https://gitlab.it-administrator.de/users/auth/openid_connect/callback". Diese URI muss exakt übereinstimmen. Bereits ein Slash am Ende der URL kann den erfolgreichen Login verhindern.

Eine Gitlab-Instanz in Ihrer Infrastruktur konfigurieren Sie passend zu den in Authentik gemachten Einstellungen. Eine Beispielkonfiguration finden Sie im Listing-Kasten.

Als nächster Schritt steht die Konfiguration der Claims in Authentik an. Diese Claims werden später im ausgestellten JSON Web Token (JWT) enthalten sein, wie in Bild 2 zu erkennen. Wenn Sie sich fragen, wie die Anwendung selbst an den öffentlichen Schlüssel gelangt, mit dem die Signatur des Tokens zu überprüfen ist, auch das hat der Standard natürlich vorgesehen. Unter der URL "https://authentik.it-administrator.de/application/o/gitlab/jwks/" findet sich eine Datei im "JSON Web Key Set"-Format, und darin sind alle kryptografischen Informationen für die Validierung der ausgestellten Token. Das ist etwas einfacher gelöst als bei SAML.

MFA mit automatischem Provisioning

Authentik unterstützt unterschiedliche Verfahren wie TOTP über die Authenticator App oder FIDO2 über das WebAuthn-Protokoll. Besonders sinnvoll ist die Kombination aus Gruppenrichtlinien und MFA-Vorgaben. Administratorenkonten oder privilegierte Gruppen können so etwa strengere Anforderungen erhalten als Standardbenutzer.

Unterstützt die Applikation den SCIM-Standard, kann Authentik Benutzer und Gruppen automatisch bereitstellen. Neue Mitarbeiter erhalten dadurch ohne weitere Einstellungen in der Anwendung selbst Zugriff auf benötigte Ressourcen. Dafür definieren Sie in Authentik, welche Gruppen oder Benutzer an die jeweilige Anwendung übertragen werden sollen.

Gerade bei Gruppenmapping und Rollenmodellen über unterschiedliche Anwendungen hinweg lohnt sich eine saubere Planung im Vorfeld. Inkonsistente Gruppennamen oder lokal gepflegte Sonderrechte führen später häufig zu schwer wartbaren Berechtigungsstrukturen. Eine baumartige Gruppenstruktur kann hier je nach Umfang der Infrastruktur die Arbeit deutlich erleichtern.

Entra ID: SSO in hybriden Microsoft-Infrastrukturen

Während Authentik als Open-Source-IdP vor allem in Self-hosted-Umgebungen beliebt ist, setzen viele Unternehmen auf Microsoft Entra ID als zentralen Identity Provider. Besonders in hybriden Infrastrukturen bietet sich der Dienst an, wenn ohnehin bereits Microsoft 365 oder Active Directory vorhanden sind.

Typisch sind Szenarien, in denen lokale Active-Directory-Benutzer per Synchronisation nach Entra ID übernommen werden. Anwendungen authentifizieren Benutzer anschließend direkt über Entra, während bestehende Gruppen- und Benutzerstrukturen erhalten bleiben. So können Sie in Ihrem Unternehmen schrittweise SSO einführen.

Für viele SaaS-Anwendungen bringt Entra ID einen kleinen Vorteil gegenüber anderen Lösungen mit. Viele Anwendungen sind bereits passend vorkonfiguriert, Confluence etwa oder zahlreiche andere Business-Plattformen lassen sich über sogenannte Enterprise Applications anbinden, ohne manuell eine Konfiguration erstellen zu müssen. Microsoft dokumentiert die Anbindung vieler Programme unter [2].

Für die Anbindung über OpenID Connect legen Sie eine neue Enterprise Application oder App Registration in Entra ID an. Anschließend definieren Sie die Redirect-URI der Zielanwendung, das ist analog zu der Konfiguration wie oben für Authentik beschrieben. Nach dem Anlegen erzeugt Entra ID automatisch die Application-ID, eine Mandanten-ID und das Client-Secret. Diese Informationen hinterlegen Sie wie gehabt in der Zielanwendung. Zusätzlich können Sie in der Konfiguration festlegen, welche Benutzerattribute und Gruppeninformationen übertragen werden sollen.

Ein wesentlicher Unterschied zu den kleineren Identity Providern liegt in den umfangreichen Conditional-Access-Funktionen von Entra ID. Darüber können Sie die Zugriffsrichtlinien abhängig von den Benutzergruppen, den Standorten der Benutzer, dem Gerätezustand oder Anmeldetypen durchsetzen. So lässt sich etwa festlegen, dass Administratoren ausschließlich von verwalteten Geräten aus auf kritische Anwendungen zugreifen dürfen oder externe Zugriffe grundsätzlich eine zusätzliche MFA-Abfrage erfordern.

Beim Benutzerlebenszyklus bietet Entra ID ebenfalls SCIM an. In der Praxis lohnt sich ein genauer Blick auf die jeweilige Anwendung. Nicht jede unterstützt das Gruppen- oder Rollenmapping so vollständig, wie Entra ID es bereitstellen kann. Teilweise werden lediglich die Benutzerkonten angelegt, während Berechtigungen weiterhin manuell gepflegt werden müssen. Wenn Sie in Ihrem Unternehmen bereits Entra ID für die reine Benutzerauthentifizierung mit Active Directory einsetzen, lässt sich dies als pragmatischer Einstieg in zentrale Identity- und Access-Management-Konzepte nutzen. Gerade hybride Szenarien profitieren davon, dass sich die bestehende AD-Strukturen direkt weiterverwenden lassen.

Lokale Konten absichern

Wenn Sie SSO konsequent einsetzen möchten, ist es wichtig, dass Sie lokale Anmeldungen in den Zielsystemen konsequent deaktivieren. Bleiben lokale Benutzerkonten aktiv, umgehen Anwender am Ende doch die zentralen Richtlinien, wie MFA, was natürlich nicht Sinn der Sache ist. Gerade bei älteren Anwendungen fällt dieser Punkt im Alltag häufig hinten runter. Für Notfälle sollten Sie sogenannte Break-Glass-Konten vorhalten. Dabei handelt es sich um streng abgesicherte lokale Administratorzugänge, die ausschließlich bei Ausfällen des zentralen Identity Providers verwendet werden sollten.

Authentik oder Entra ID: Entscheidungskriterien

Welcher Identity Provider sich für eine Umgebung eignet, hängt weniger von einzelnen Features ab als von den bestehenden Betriebsmodellen und organisatorischen Anforderungen. In der Praxis unterscheiden sich die Ansätze von Authentik und Microsoft Entra ID durchaus etwas. Authentik eignet sich besonders für Unternehmen, die einen zentralen Identity Provider selbst betreiben möchten und dabei OIDC- und SAML-Integrationen benötigen. Authentik bietet einen guten Mittelweg zwischen Funktionsumfang und Kontrolle über die eigene Umgebung.

Entra ID spielt seine Stärken vor allem in bestehenden Microsoft-Infrastrukturen aus. Unternehmen profitieren hier insbesondere von der engen Integration in Microsoft 365, Hybrid-AD-Szenarien und umfangreichen Conditional-Access-Funktionen. Gerade in größeren Organisationen erleichtert das die zentrale Steuerung von Zugriffsrichtlinien erheblich, wenngleich damit natürlich auch die Abhängigkeit vom Microsoft-Ökosystem steigt.

Selbstverständlich gibt es über diese beiden Produkte hinaus noch viele weitere Anbieter mit ähnlichem Funktionsumfang. Für Ihr Unternehmen sollte die Entscheidungsgrundlage daher weniger aus einzelnen technischen Funktionen bestehen als vielmehr aus der Frage, welche Plattform sich am sinnvollsten in die bestehende IT-Infrastruktur und Unternehmensprozesse integrieren lässt.

Fazit

Single Sign-on allein löst die Herausforderungen moderner IT-Umgebungen nicht vollständig. Die Kombination aus zentraler Authentifizierung, konsequenter MFA-Durchsetzung und automatisiertem Benutzer-Provisioning schafft aber eine wartbare und sichere Identity-Architektur. Planen Sie die Einführung deshalb nicht als einmaliges Projekt, sondern als fortlaufenden Prozess. Beginnen Sie mit unkritischen Anwendungen, sammeln Sie dort Erfahrungen mit Claims, Gruppenmapping und Session-Handling, und erweitern Sie die Anbindung erst anschließend schrittweise auf geschäftskritische Systeme.

Wer von Anfang an saubere Namenskonventionen für Gruppen und Rollen etabliert, erspart sich später mühsames Aufräumen in gewachsenen Berechtigungsstrukturen. Am Ende zahlt sich diese Sorgfalt aus: Statt einzelner Inselsysteme entsteht eine zusammenhängende Identity-Landschaft, in der Sie Zugriffe zentral steuern, nachvollziehen und im Ernstfall auch schnell wieder einschränken können.

In diesem Artikel haben wir gezeigt, wie Sie in Ihrem Unternehmen Authentik oder Entra ID einsetzen können. Wenn Sie dabei Single Sign-on lediglich als Komfortfunktion betrachten, verschenken Sie mitunter einen großen Teil des Potentials von IAM-Umgebungen.

Single Sign-on für Collaboration-Anwendungen mit OIDC, SAML und SCIM