PeachShutterStock | shutterstock.com

Im Kern der Enterprise Security steht die Zerreißprobe zwischen Benutzerkomfort und Security-Anforderungen. Dabei handelt es sich um einen Balanceakt, der regelmäßig auf Authentifizierungsebene ausgetragen wird und sich direkt auf das Onboarding- und Anmeldeerlebnis auswirkt. Geht es darum diesen Konflikt aufzulösen, steht Federated Identity an vorderster Front: Sie kann eine gute User Experience bieten, ohne dabei das Sicherheitsniveau zu beeinträchtigen.

Federated Identity Management – Definition

Identity & Access Management (IAM) ist der übergeordnete Bereich, in dem es um digitale Identitäten und Zugriffsmanagement geht. Federated Identity Management (oder förderiertes Identitätsmanagement) ist eine IAM-Kategorie, die darauf fokussiert, ein einziges Authentifizierungsereignis sicher zu ermöglichen, um mehrere Interaktionen oder den Austausch von Identitätsinformationen abzudecken. Mit anderen Worten: Federated Identity Management (FIM) ermöglicht vielen Diensten, eine einzige digitale Identität gemeinsam zu nutzen. Ein Beispiel für den praktischen Einsatz von FIM wäre, wenn Sie sich bei Twitter mit ihrem Google-Konto anmelden.

Föderiertes Identitätsmanagement kann der Benutzererfahrung, der allgemeinen Sicherheit und der Ausfallsicherheit zuträglich sein. Dafür gilt es, folgende Kompromisse einzugehen:

• erhöhte architektonische Komplexität,

• Bindung an einen bestimmten Anbieter und

• mögliche Servicekosten.

Federated Identity Management wird bisweilen mit Single Sign-On (SSO) in einen Topf geworfen. Genau genommen ist SSO allerdings eine Funktion von FIM – und einer seiner wesentlichen Use Cases, den wir im Folgenden näher betrachten. Zuvor noch ein Hinweis: Das Thema Self-Sovereign Identity (oder dezentrale Identität) ist wieder eine andere Baustelle.

Anwendungsfall (Federated) Single-Sign On

Man unterscheidet zwei Arten von Single Sign-on: Einerseits das, was für Anwendungen innerhalb einer einzelnen Organisation gilt, und andererseits das, was organisationsübergreifend gilt. Ersteres wird in der Regel einfach als Single Sign-on bezeichnet, manchmal auch als “Enterprise Single Sign-on”. Letzteres fällt unter den Begriff Federated Single Sign-on (FSSO).

Die High-Level-Architektur, um beide SSO-Formen abzudecken, sieht folgendermaßen aus:

Foto: Foundry / Matthew Tyson

In jedem Fall erfordert Federated Identity Management eine zentrale Institution, die die gemeinsamen Anmeldeinformationen zwischen den verschiedenen Diensten vermittelt. Dabei kann es sich um einen Identity Manager handeln, der:

• von der Organisation selbst erstellt wurde (etwa unter Verwendung von Active Directory).

• über einen Identitätsanbieter in unterschiedlichem Umfang bereitgestellt wird.

Enterprise Single Sign-on deckt oft Situationen ab, in denen sich Mitarbeiter mehrfach bei internen Systemen anmelden müssen, beispielsweise an HR-Portal und IT-Ticketsystem. Dieses Konzept birgt offensichtliche UX-, aber auch systemische Probleme, weil Identitätsinformationen über heterogene Systeme verteilt werden. Dieser Umstand beeinträchtigt die Sicherheit und erschwert es, Richtlinien durchzusetzen. So müssen etwa bei On- und Off-Boarding eines Mitarbeiters gleich zwei verschiedene Datenspeicher geändert werden.

Federated Single Sign-on ermöglicht die gemeinsame Nutzung von Anmeldeinformationen über Unternehmensgrenzen hinweg. Als solches stützt es sich in der Regel auf eine große, gut etablierte Einheit mit weitreichendem Trust – beispielsweise Google, Microsoft oder Amazon. Selbst eine kleine Applikation kann relativ einfach um die Option “Anmelden bei Google” ergänzt werden und den Nutzern eine einfache Anmeldemöglichkeit bieten, bei der sensible Informationen in den Händen der großen Organisation bleiben.

Federated SSO implementieren

Der Aufbau einer Federated SSO-Lösung richtet sich nach den jeweils spezifischen Anforderungen. Die allgemeinen Schritte sind dabei jedoch identisch:

• Identity Provider einrichten: Entweder, Sie stellen eine zentralisierte Identity Infrastructure bereit oder Sie richten ein Konto bei einem Federated-Identity-Anbieter ein (Google, Microsoft, Okta). Auch eine Möglichkeit: Sie kreieren eine Mischform.

• Provider mit Anwendungsinformationen füttern: So konfigurieren Sie den Identity Provider und schaffen die Grundlage, dass sich Applikationen mit dem Anbieter verbinden können.

• Provider-Anmeldeinformationen hinzufügen: Diese werden Sie im nächsten Schritt verwenden, um Ihren Anwendungen mitzuteilen, wie sie sich authentifizieren sollen.

• Applikationen einrichten: In Ihrem Anwendungscode fügen Sie Abhängigkeiten für die Authentifizierung und Interaktion mit dem Identity-Provider-Service hinzu.

• Neue Authentifizierung integrieren: Mit dem konfigurierten SSO-Service haben Ihre Benutzer eine Möglichkeit, sich zu authentifizieren. Das funktioniert auch in “transparent”: Anwendungen erkennen und authentifizieren User mit einer Live-Session bei einem anderen Service automatisch.

Weil es eine einfache Lösung ist, entscheiden sich die meisten Unternehmen heute für einen Cloud Identity Provider im Rahmen eines SaaS-Angebots – sowohl, wenn es um Enterprise als auch wenn es um Federated SSO geht.

SSO-Protokolle implementieren

Für SSO-Interaktionen werden im Wesentlichen drei Protokolle verwendet: SAML, OIDC und OAuth 2.0. Je nachdem, welches Protokoll der von Ihnen verwendete Identity-Anbieter unterstützt, werden Sie eines davon verwenden, um die sicheren Token-Informationen zwischen Ihren Anwendungen zu übermitteln. Jedes der Protokolle stellt einen offenen Standard dar, der auf einen bestimmten Anwendungsfall ausgerichtet ist.

• SAML ist ein XML-basiertes Protokoll, das häufig in Unternehmen verwendet wird, um Enterprise SSO zu unterstützen oder um zwischen verschiedenen Business-Service-Anbietern hin- und herzuspringen. Es kann auch für die allgemeine gemeinsame Nutzung von Identitäten verwendet werden, einschließlich Federated SSO (insofern der Identity Provider das unterstützt).

• OAuth 2.0 ist ein Authentifizierungsprotokoll, das die gemeinsame Nutzung von Ressourcendaten zwischen Anbietern auf der Grundlage der Zustimmung des Benutzers ermöglicht. Oauth fokussiert auf die gemeinsame Nutzung der Authentifizierung zwischen Diensten ohne die Angabe von Anmeldeinformationen.

• OIDC (OpenID Connect) stellt eine auf OAuth 2.0 aufbauende Schicht dar, die in der Regel für Social Logins (etwa “Sign in with GitHub”) verwendet wird. OIDC enthält einige Erweiterungen gegenüber OAuth, einschließlich Identity Assertions, Userinfo API und Standard Discovery – standardisierte Mechanismen für die sichere Bereitstellung und Nutzung von Identitätsinformationen.

Diese Protokolle kommen einzeln oder im Kombination mit anderen Technologien zum Einsatz. So können beispielsweise JSON Web Token verwendet werden, um OAuth 2.0 Credential Token-Informationen in einem sichereren Format zu kapseln.

Glücklicherweise ist der Prozess zur Implementierung dieser Protokolle umfassend dokumentiert und wird von einer Vielzahl von Technologie-Stacks unterstützt. Der größte Teil der Arbeit wird durch Abstraktionen auf höherer Ebene in vielen Sprachen und Frameworks gekapselt. Spring Security bietet beispielsweise SSO-Unterstützung, ebenso wie Passport im NodeJS/Express-Ökosystem. (fm)