PeachShutterStock | shutterstock.com
Im Kern jeder Enterprise-Security-Strategie tobt ein konstanter Konflikt: Benutzerkomfort versus Sicherheitsanforderungen. Dieser Balanceakt entscheidet sich regelmäßig auf der Authentifizierungsebene – mit spürbaren Auswirkungen auf Onboarding- und Login-Erlebnisse. Federated Identity ist dabei ein zentraler Lösungsansatz: Sie verspricht eine überzeugende User Experience, ohne das Sicherheitsniveau zu opfern.
Federated Identity Management – Definition
Identity & Access Management (IAM) ist der übergeordnete Rahmen für die Verwaltung digitaler Identitäten und Zugriffsrechte. Federated Identity Management (föderiertes Identitätsmanagement) ist eine IAM-Unterkategorie mit einem klaren Fokus: Ein einziges Authentifizierungsereignis soll ausreichen, um mehrere Dienste oder den systemübergreifenden Austausch von Identitätsinformationen abzusichern. Im Kern erlaubt Federated Identity Management (FIM) verschiedenen Diensten, eine gemeinsame digitale Identität zu nutzen. Ein alltägliches Beispiel: die Anmeldung bei Twitter über das eigene Google-Konto.
Föderiertes Identitätsmanagement kann die Benutzererfahrung verbessern, das Sicherheitsniveau erhöhen und die Ausfallsicherheit steigern. Diese Vorteile haben jedoch ihren Preis:
erhöhte architektonische Komplexität,
Abhängigkeit von einem bestimmten Anbieter sowie
mögliche Servicekosten.
Federated Identity Management wird häufig mit Single Sign-On (SSO) gleichgesetzt. Genau genommen ist SSO jedoch eine Funktion von FIM – und einer seiner wichtigsten Anwendungsfälle, dem wir uns im Folgenden widmen. Ein ergänzender Hinweis: Das Thema Self-Sovereign Identity (auch dezentrale Identität) ist ein eigenständiges Thema und wird hier nicht behandelt.
Anwendungsfall: (Federated) Single Sign-On
Single Sign-On existiert in zwei grundlegenden Ausprägungen: zum einen für Anwendungen innerhalb einer einzelnen Organisation, zum anderen für organisationsübergreifende Szenarien. Ersteres wird schlicht als Single Sign-On oder auch als „Enterprise Single Sign-On" bezeichnet. Letzteres fällt unter den Begriff Federated Single Sign-On (FSSO).
Die High-Level-Architektur, die beide SSO-Varianten abdeckt, sieht folgendermaßen aus:
Der Blick auf eine High-Level-SSO-Architektur.
Foto: Foundry / Matthew Tyson
In beiden Fällen setzt Federated Identity Management eine zentrale Instanz voraus, die Anmeldeinformationen zwischen den beteiligten Diensten vermittelt. Diese Instanz kann sein:
eine von der Organisation selbst aufgebaute Identity Infrastructure (etwa auf Basis von Active Directory),
ein externer Identitätsanbieter, der im gewünschten Umfang genutzt wird.
Enterprise Single Sign-On adressiert typischerweise Szenarien, in denen Mitarbeiter sich wiederholt bei internen Systemen anmelden müssen – etwa am HR-Portal und am IT-Ticketsystem. Das Problem: Identitätsdaten werden über heterogene Systeme verteilt, was nicht nur die User Experience belastet, sondern auch die Durchsetzung von Sicherheitsrichtlinien erschwert. So müssen beim On- und Offboarding eines Mitarbeiters gleich mehrere Datenspeicher aktualisiert werden.
Federated Single Sign-On geht einen Schritt weiter und ermöglicht die gemeinsame Nutzung von Anmeldeinformationen über Unternehmensgrenzen hinweg. Es stützt sich dabei in der Regel auf etablierte, vertrauenswürdige Akteure wie Google, Microsoft oder Amazon. Selbst kleine Anwendungen können damit unkompliziert eine „Mit Google anmelden"-Option integrieren – und ihren Nutzern eine komfortable Authentifizierung bieten, bei der sensible Daten in den Händen der großen Plattformanbieter verbleiben.
Federated SSO implementieren
Die konkrete Umsetzung einer Federated-SSO-Lösung hängt von den spezifischen Anforderungen ab. Die grundlegenden Schritte sind jedoch weitgehend identisch:
Identity Provider einrichten: Entweder Sie bauen eine eigene zentrale Identity Infrastructure auf, richten ein Konto bei einem Federated-Identity-Anbieter wie Google, Microsoft oder Okta ein – oder Sie entscheiden sich für einen hybriden Ansatz.
Provider mit Anwendungsinformationen konfigurieren: Damit schaffen Sie die Voraussetzung, dass sich Ihre Applikationen mit dem Identity Provider verbinden können.
Provider-Anmeldeinformationen hinterlegen: Diese Credentials werden im nächsten Schritt benötigt, um den Anwendungen mitzuteilen, wie sie sich authentifizieren sollen.
Applikationen einrichten: Im Anwendungscode fügen Sie die notwendigen Abhängigkeiten für die Authentifizierung und die Kommunikation mit dem Identity-Provider-Service hinzu.
Neue Authentifizierung integrieren: Mit dem konfigurierten SSO-Service steht Benutzern ein durchgängiger Authentifizierungsmechanismus zur Verfügung – inklusive transparenter Variante, bei der Anwendungen aktive Sessions bei anderen Diensten automatisch erkennen und nutzen.
Da Cloud-basierte Lösungen die Implementierung erheblich vereinfachen, setzen die meisten Unternehmen heute auf einen Cloud Identity Provider im Rahmen eines SaaS-Angebots – sowohl für Enterprise als auch für Federated SSO.
SSO-Protokolle implementieren
Für SSO-Interaktionen kommen im Wesentlichen drei Protokolle zum Einsatz: SAML, OIDC und OAuth 2.0. Welches dieser Protokolle genutzt wird, hängt vom jeweiligen Identity-Anbieter ab – es bestimmt, wie Token-Informationen sicher zwischen den Anwendungen übertragen werden. Alle drei sind offene Standards, die auf spezifische Anwendungsfälle ausgerichtet sind:
SAML ist ein XML-basiertes Protokoll, das vor allem im Unternehmensumfeld verbreitet ist. Es unterstützt Enterprise SSO sowie die Authentifizierung zwischen verschiedenen Business-Service-Anbietern und kann – sofern der Identity Provider dies vorsieht – auch für Federated SSO eingesetzt werden.
OAuth 2.0 ist ein Autorisierungsprotokoll, das die gemeinsame Nutzung von Ressourcendaten zwischen Diensten auf Basis der Nutzereinwilligung ermöglicht. Im Fokus steht dabei der geteilte Zugriff auf Ressourcen – ohne dass Anmeldeinformationen direkt weitergegeben werden müssen.
OIDC (OpenID Connect) ist eine Identitätsschicht, die auf OAuth 2.0 aufsetzt und typischerweise für Social Logins wie „Sign in with GitHub" genutzt wird. OIDC erweitert OAuth um Identity Assertions, eine Userinfo API sowie einen Standard-Discovery-Mechanismus – und standardisiert damit die sichere Bereitstellung und Verarbeitung von Identitätsinformationen.
Diese Protokolle können einzeln oder in Kombination mit anderen Technologien eingesetzt werden. So lassen sich etwa JSON Web Tokens verwenden, um OAuth-2.0-Credential-Token-Informationen in einem zusätzlich gesicherten Format zu kapseln.
Die gute Nachricht: Die Implementierung dieser Protokolle ist umfassend dokumentiert und wird von einer Vielzahl von Technologie-Stacks unterstützt. Höher abstrahierte Bibliotheken in zahlreichen Sprachen und Frameworks nehmen Entwicklern den Großteil der Arbeit ab. Spring Security bietet beispielsweise integrierte SSO-Unterstützung, ebenso wie Passport im NodeJS/Express-Ökosystem. (fm)
