Föderiertes Identitätsmuster

Delegieren Sie die Benutzerauthentifizierung an einen externen Identitätsanbieter (IdP), um die Entwicklung zu vereinfachen, administrative Aufgaben zu minimieren und die Anwendungs-UX zu verbessern.

Kontext und Problem

Benutzer müssen in der Regel mit mehreren Anwendungen arbeiten, die Partnerorganisationen bereitstellen und hosten. Möglicherweise müssen sie bestimmte, unterschiedliche Anmeldeinformationen für jede Anwendung verwenden. Diese Anforderung kann:

• Eine uneinheitliche UX verursachen. Mitarbeiter vergessen häufig mehrere Anmeldeinformationen.

• Sicherheitslücken aufdecken. Wenn ein Mitarbeiter das Unternehmen verlässt, muss die Organisation das Konto sofort deaktivieren. Große Organisationen verpassen diesen kritischen Schritt häufig.

• Komplizieren Sie die Benutzerverwaltung. Administratoren verwalten Benutzeranmeldeinformationen, geben Kennworterinnerungen aus und führen andere administrative Aufgaben aus.

Benutzer verwenden in der Regel die gleichen Anmeldeinformationen für alle Anwendungen.

Lösung

Implementieren Sie einen Verbundidentitätsauthentifizierungsmechanismus. Trennen Sie die Benutzerauthentifizierung vom Anwendungscode und delegieren Sie die Authentifizierung an einen vertrauenswürdigen IdP. Dieser Prozess vereinfacht die Entwicklung, minimiert den Verwaltungsaufwand und stellt die Benutzerauthentifizierung über einen Bereich von IDPs bereit. Verbundidentität trennt auch die Authentifizierung von der Autorisierung.

Vertrauenswürdige IDPs umfassen Unternehmensverzeichnisse, lokale Verbunddienste, Sicherheitstokendienste (STSs) und Social IdPs wie Microsoft, Google, Yahoo! oder Facebook.

Das folgende Diagramm zeigt das Verbundidentitätsmuster für eine Clientanwendung, die auf einen Dienst zugreift, der eine Authentifizierung erfordert. Der IdP arbeitet mit einem STS zur Authentifizierung. Der IdP stellt Sicherheitstoken aus, die Informationen zu dem authentifizierten Benutzer bereitstellen. Diese Informationen, die als Ansprüche bezeichnet werden, umfassen die Identität des Benutzers und können auch andere Ansprüche enthalten, z. B. Rollenmitgliedschaften und genauere Zugriffsrechte.

Dieses Modell wird auch als anspruchsbasierte Zugriffssteuerung bezeichnet. Anwendungen und Dienste autorisieren den Zugriff auf Features und Funktionen basierend auf den Ansprüchen. Der Dienst, der eine Authentifizierung anfordert, muss dem IdP vertrauen. Die Clientanwendung kontaktiert den IdP für die Authentifizierung. Wenn die Authentifizierung erfolgreich ist, gibt der IdP ein Token zurück, das benutzeridentifizierende Ansprüche an den STS enthält. Der IdP und der STS sind möglicherweise Teil desselben Diensts. Der STS kann die Ansprüche basierend auf vordefinierten Regeln transformieren und erweitern, bevor es das Token an den Client zurückgibt. Die Clientanwendung übergibt dieses Token dann als Nachweis seiner Identität an den Dienst.

Die Verbundauthentifizierung bietet eine standardsbasierte Methode zum Einrichten der Vertrauensstellung in Identitäten über Domänen hinweg und unterstützt einmaliges Anmelden (Single Sign-On, SSO). Viele Anwendungen, insbesondere in der Cloud gehostete Anwendungen, verwenden die Verbundauthentifizierung, da sie SSO ohne direkte Netzwerkverbindung zu einem IdP unterstützt. Dieses Design erhöht die Sicherheit, da der Benutzer keine unterschiedlichen Anmeldeinformationen für mehrere Anwendungen erstellen und eingeben muss. Außerdem begrenzt es die Offenlegung von Anmeldeinformationen auf den ursprünglichen IdP. Anwendungen sehen nur die authentifizierten Identitätsinformationen im Token.

Anwendungen und Dienste, die die Verbundauthentifizierung verwenden, müssen keine Identitätsverwaltungsfeatures bereitstellen. Stattdessen ist der IdP für die Identitäts- und Anmeldeinformationsverwaltung verantwortlich. Wenn das Unternehmensverzeichnis dem IdP vertraut, muss die Benutzeridentität nicht verwaltet werden. Bei diesem Ansatz wird der Verwaltungsaufwand für die verzeichnisbasierte Benutzeridentitätsverwaltung beseitigt.

Probleme und Überlegungen

Beachten Sie die folgenden Punkte bei Ihrer Entscheidung, wie dieses Muster implementiert werden soll:

• Authentifizierung kann ein Single Point of Failure sein. Um die Zuverlässigkeit und Verfügbarkeit von Anwendungen in mehreren Regionen aufrechtzuerhalten, sollten Sie den Identitätsverwaltungsmechanismus in denselben Regionen wie Ihre Anwendung bereitstellen.

• Verwenden Sie zum Konfigurieren der rollenbasierten Zugriffssteuerung (RBAC) Authentifizierungstools. RBAC unterstützt eine präzise Kontrolle über Features und Ressourcenzugriff.

• Im Gegensatz zu einem Unternehmensverzeichnis stellt die anspruchsbasierte Authentifizierung, die social IdPs verwendet, in der Regel nur die E-Mail-Adresse des authentifizierten Benutzers und manchmal ihren Namen bereit. Einige social IdPs, z. B. Microsoft, stellen nur einen eindeutigen Bezeichner bereit. Die Anwendung verwaltet in der Regel einige Informationen zu registrierten Benutzern, damit diese Informationen mit dem Bezeichner in den Ansprüchen übereinstimmen können. Diese Aufgabe wird in der Regel während der Registrierung abgeschlossen, wenn der Benutzer zum ersten Mal auf die Anwendung zugreift. Anschließend werden Informationen nach jeder Authentifizierung als neue Ansprüche in das Token eingefügt.

• Wenn mehrere IDPs für den STS konfiguriert sind, muss der STS bestimmen, welcher IdP den Benutzer authentifizieren soll. Dieser Prozess wird als Home Realm Discovery bezeichnet. Der STS kann den IdP automatisch basierend auf den vom Benutzer bereitgestellten Informationen wie einer E-Mail-Adresse oder einem Benutzernamen, der Anwendungsdomäne, dem IP-Adressbereich des Benutzers oder einem Cookie ermitteln, der im Browser des Benutzers gespeichert ist. Wenn der Benutzer beispielsweise eine Microsoft-E-Mail-Adresse eingibt, wie user@live.com, leitet der STS den Benutzer zur Anmeldeseite für das Microsoft-Konto weiter. Bei nachfolgenden Besuchen kann der STS ein Cookie verwenden, das angibt, dass der Benutzer zuvor mit einem Microsoft-Konto angemeldet ist. Wenn der STS die Heimatdomäne nicht automatisch bestimmen kann, zeigt er eine Seite zur Ermittlung der Heimatdomäne an, auf der die vertrauenswürdigen IdPs aufgelistet sind. Der Benutzer wählt dann einen IdP aus.

Wann dieses Muster verwenden

Verwenden Sie dieses Muster bei Bedarf:

• SSO im Unternehmen. In diesem Szenario müssen Sie Mitarbeiter für Unternehmensanwendungen authentifizieren, die außerhalb der Unternehmenssicherheitsgrenze in der Cloud gehostet werden, ohne sich bei jedem Besuch einer Anwendung anzumelden. Die Benutzeroberfläche stimmt mit lokalen Anwendungen überein. Benutzer authentifizieren sich, wenn sie sich beim Unternehmensnetzwerk anmelden, und dann können sie ohne eine andere Anmeldung auf relevante Anwendungen zugreifen.

• Verbundidentität mit mehreren Partnern. In diesem Szenario müssen Sie Unternehmensmitarbeiter und Geschäftspartner authentifizieren, die nicht über Konten im Unternehmensverzeichnis verfügen. Diese Praxis ist üblich in Geschäfts-zu-Geschäfts-Anwendungen, Anwendungen, die in Partnerdienste integriert sind, und in Unternehmen, die unterschiedliche IT-Systeme verwenden, oder zusammengeführte oder gemeinsam genutzte Ressourcen.

• Föderierte Identität in SaaS-Anwendungen. In diesem Szenario bieten unabhängige Softwareanbieter einen einsatzbereiten Dienst für mehrere Clients oder Mandanten. Mandanten authentifizieren sich mithilfe eines geeigneten IdP. Beispielsweise verwenden Geschäftsbenutzer ihre Unternehmensanmeldeinformationen, während Mandantenconsumer und Kunden Anmeldedaten sozialer Identitäten verwenden.

• Föderierte Identität für den Zugriff auf Workloads. In diesem Szenario müssen Mandantenanwendungen, Automatisierungsworkflows oder kontinuierliche Integration und kontinuierliche Übermittlungssysteme Ihre APIs aufrufen, ohne dass ein Benutzer vorhanden ist. Mandanten authentifizieren sich über ihre eigenen IdPs unter Verwendung von Workloadidentitäten. Die Anwendung autorisiert den Zugriff mithilfe der Überprüfung des mandantenbezogenen Anspruchs.

Dieses Muster eignet sich möglicherweise nicht, wenn Sie folgendes haben:

• Ein IdP. In diesem Szenario authentifizieren sich Anwendungsbenutzer mithilfe eines IdP und müssen sich nicht mit einem anderen IdP authentifizieren. Diese Situation ist typisch für Anwendungen, die ein Unternehmensverzeichnis für die Authentifizierung verwenden, entweder über ein VPN oder eine virtuelle Netzwerkverbindung zwischen der Anwendung und einem lokalen Verzeichnis.

• Inkompatible Authentifizierungsmechanismen. In diesem Szenario verwendet die Anwendung einen anderen Authentifizierungsmechanismus, z. B. mithilfe von benutzerdefinierten Benutzerspeichern oder kann keine anspruchsbasierten Technologieverhandlungsstandards verarbeiten. Es kann komplex und teuer sein, anspruchsbasierte Authentifizierung und Zugriffssteuerung in eine vorhandene Anwendung nachzurüsten.

Arbeitslastgestaltung

Bewerten Sie, wie Sie das Verbundidentitätsmuster im Entwurf einer Workload verwenden, um die in den Azure Well-Architected Framework-Säulen behandelten Ziele und Prinzipien zu erfüllen. Die folgende Tabelle enthält Anleitungen dazu, wie dieses Muster die Ziele jeder Säule unterstützt.

Wenn dieses Muster Kompromisse innerhalb einer Säule einführt, sollten Sie sie gegen die Ziele der anderen Säulen berücksichtigen.

Example

Eine Organisation hostet eine mehrkomponentige cloudbasierte Anwendung, die ein Web-Front-End und eine Back-End-API umfasst. Die Anwendung delegiert die Authentifizierung an einen zentralen IdP mithilfe von Microsoft Entra ID, anstatt Authentifizierungslogik in jeder Komponente zu implementieren.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Der folgende Workflow entspricht dem vorherigen Diagramm.

1. Der Benutzer greift auf die Web-App zu.

2. Die Web-App leitet den Benutzer zur Microsoft Entra ID zur Authentifizierung um.

3. Nach erfolgreicher Authentifizierung leitet Microsoft Entra ID den Benutzer mit einem Autorisierungscode zurück an die Web-App weiter.

4. Die Web-App austauscht den Autorisierungscode für Token und sendet eine POST-Anforderung an den Tokenendpunkt.

5. Microsoft Entra ID gibt ein Token aus, das Ansprüche über den Benutzer enthält.

6. Die Web-App verwendet dieses Token, um eine Back-End-API aufzurufen.

7. Die Web-App und die Back-End-API überprüfen das Token und erzwingen ihre Autorisierungsregeln basierend auf den Ansprüchen.

8. Die API gibt die Antwort auf die Web-App zurück.

Wichtige Merkmale:

• Zentralisierte Authentifizierung. Komponenten basieren auf Microsoft Entra ID zum Authentifizieren von Benutzern, wodurch die Notwendigkeit einer benutzerdefinierten Authentifizierungslogik in der Anwendung aufgehoben wird.

• Dezentrale Autorisierung. Anwendungskomponenten erzwingen unabhängig Autorisierungsentscheidungen basierend auf Ansprüchen.

• Anspruchsbasierte Zugriffssteuerung. Der Zugriff auf Funktionen wird mithilfe von Ansprüchen wie Rollen oder Bereichen bestimmt.

• Standardbasierte Protokolle. Komponenten verwenden OAuth 2.0 und OpenID Connect für die Authentifizierung.

• Optionale MFA-Erzwingung. Wenn Ihr Risikoprofil eine stärkere Anmeldesicherheit erfordert, können Sie die mehrstufige Authentifizierung mithilfe von Richtlinien für bedingten Zugriff in Microsoft Entra ID erzwingen.

• Optionale Erweiterbarkeit durch Föderation. Microsoft Entra ID kann mithilfe von mandantenübergreifenden Zugriffseinstellungen so konfiguriert werden, dass einem Microsoft Entra-Mandanten eines Partners vertraut wird. Partnerbenutzer können dann ohne Änderungen an Anwendungskomponenten auf die Anwendung zugreifen.

Nächste Schritte

• Was ist Microsoft Entra?
• OpenID Connect auf der Microsoft-Identitätsplattform
• Eine Einzelmandanten-App mithilfe von Microsoft Entra ID in eine App für mehrere Mandanten umwandeln
• Was ist bedingter Zugriff?

Zugehörige Ressourcen

• Architekturüberlegungen zur Identität in einer multiinstanzenübergreifenden Lösung
• Muster „Gatekeeper“
• Muster „Valetschlüssel“.
• Muster „Gatewayabladung“