Zugriff auf extern authentifizierte Benutzer (Identity Federation) - AWS Identitäts- und Zugriffsverwaltung

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Zugriff auf extern authentifizierte Benutzer (Identity Federation)

Ihre Benutzer haben möglicherweise bereits Identitäten außerhalb von AWS, z. B. in Ihrem Unternehmensverzeichnis. Wenn diese Benutzer mit AWS Ressourcen arbeiten müssen (oder mit Anwendungen arbeiten müssen, die auf diese Ressourcen zugreifen), benötigen diese Benutzer auch AWS Sicherheitsanmeldeinformationen. Sie können eine IAM Rolle verwenden, um Berechtigungen für Benutzer anzugeben, deren Identität mit Ihrer Organisation oder einem externen Identitätsanbieter (IdP) verbunden ist.

Anmerkung

Aus Sicherheitsgründen empfehlen wir, den Benutzerzugriff in IAMIdentity Center mit einem Identitätsverbund zu verwalten, anstatt Benutzer zu erstellenIAM. Informationen zu bestimmten Situationen, in denen ein IAM Benutzer erforderlich ist, finden Sie unter Wann sollte ein IAM Benutzer (statt einer Rolle) erstellt werden?

Zusammenführung von Benutzern einer mobilen oder webbasierten Anwendung mit Amazon Cognito

Wenn Sie eine mobile oder webbasierte App erstellen, die auf AWS Ressourcen zugreift, benötigt die App Sicherheitsanmeldedaten, um programmatische Anfragen an sie stellen zu können. AWS Für die meisten mobilen Anwendungsszenarien empfehlen wir die Verwendung von Amazon Cognito. Sie können diesen Dienst mit AWS Mobile SDK for iOS und AWS Mobile SDK for Android und Fire OS verwenden, um eindeutige Identitäten für Benutzer zu erstellen und sie für den sicheren Zugriff auf Ihre AWS Ressourcen zu authentifizieren. Amazon Cognito unterstützt die Identitätsanbieter, die im nächsten Abschnitt aufgeführt werden, sowie die vom Entwickler authentifizierten Identitäten und nicht authentifizierten Zugriff (Gast). Amazon Cognito bietet auch API Funktionen zum Synchronisieren von Benutzerdaten, sodass sie erhalten bleiben, wenn Benutzer zwischen Geräten wechseln. Weitere Informationen finden Sie unter Amazon Cognito für mobile Apps.

Vereinigen von Benutzern in einem Verbund mit öffentlichen Identitätsdienstanbietern oder OpenID Connect

Verwenden Sie möglichst Amazon Cognito für mobile und webbasierte Anwendungsszenarien. Amazon Cognito erledigt den Großteil der behind-the-scenes Arbeit mit öffentlichen Identitätsanbieterdiensten für Sie. Es funktioniert mit den gleichen Drittanbieterservices und unterstützt auch anonyme Anmeldungen. Für fortgeschrittenere Szenarien können Sie jedoch direkt mit einem Drittanbieter-Service wie Login with Amazon, Facebook, Google oder einem anderen IdP arbeiten, der mit OpenID Connect () OIDC kompatibel ist. Weitere Informationen zur Verwendung des OIDC Verbunds mithilfe eines dieser Dienste finden Sie unter. OIDCföderation

Benutzer mit 2.0 verbinden SAML

Wenn Ihre Organisation bereits ein Identity Provider-Softwarepaket verwendet, das SAML 2.0 (Security Assertion Markup Language 2.0) unterstützt, können Sie Vertrauen zwischen Ihrer Organisation als Identity Provider (IdP) und AWS als Service Provider aufbauen. Sie können es dann verwendenSAML, um Ihren Benutzern föderiertes Single-Sign-On (SSO) AWS Management Console oder Verbundzugriff auf Anrufvorgänge bereitzustellen. AWS API Wenn Ihr Unternehmen beispielsweise Microsoft Active Directory und Active Directory Federation Services verwendet, können Sie den Verbund mithilfe von SAML 2.0 durchführen. Weitere Informationen zum Verbinden von Benutzern mit SAML 2.0 finden Sie unter. SAML2.0-Föderation

Vereinigen von Benutzern in einem Verbund durch Erstellen einer benutzerdefinierten Identity Broker-Anwendung

Wenn Ihr Identitätsspeicher nicht mit SAML 2.0 kompatibel ist, können Sie eine benutzerdefinierte Identity Broker-Anwendung erstellen, die eine ähnliche Funktion ausführt. Die Broker-Anwendung authentifiziert Benutzer, fordert temporäre Anmeldeinformationen für Benutzer an AWS und stellt sie dann dem Benutzer für den Zugriff auf AWS Ressourcen zur Verfügung.

Beispielsweise hat Example Corp. viele Mitarbeiter, die interne Anwendungen ausführen müssen, die auf die Ressourcen des AWS Unternehmens zugreifen. Die Mitarbeiter verfügen bereits über Identitäten im Identitäts- und Authentifizierungssystem des Unternehmens, und Example Corp. möchte nicht für jeden Mitarbeiter des Unternehmens einen eigenen IAM Benutzer erstellen.

Bob ist Entwickler bei Example Corp. Damit interne Anwendungen von Example Corp. auf die AWS Ressourcen des Unternehmens zugreifen können, entwickelt Bob eine benutzerdefinierte Identity Broker-Anwendung. Die Anwendung überprüft, ob die Mitarbeiter beim vorhandenen Identitäts- und Authentifizierungssystem von Example Corp. angemeldet sind, das Active Directory oder ein LDAP anderes System verwenden kann. Die Identity Broker-Anwendung ruft dann die temporären Anmeldeinformationen für die Mitarbeiter ab. Dieses Szenario ähnelt dem vorherigen Szenario (eine mobile App, die ein benutzerdefiniertes Authentifizierungssystem verwendet), mit der Ausnahme, dass die Anwendungen, die Zugriff auf AWS Ressourcen benötigen, alle innerhalb des Unternehmensnetzwerks ausgeführt werden und das Unternehmen über ein vorhandenes Authentifizierungssystem verfügt.

Zum Abrufen von temporären Sicherheitsanmeldeinformationen ruft die Identity Broker-Anwendung entweder AssumeRole oder GetFederationToken auf, je nachdem, wie Bob die Richtlinien für die Benutzer verwalten möchte und wann die temporären Anmeldeinformationen ablaufen sollen. (Weitere Informationen zu den Unterschieden zwischen diesen API Vorgängen finden Sie unter Temporäre Sicherheitsnachweise in IAM undBerechtigungen für temporäre Sicherheitsanmeldedaten.) Der Aufruf gibt temporäre Sicherheitsanmeldeinformationen zurück, die aus einer AWS Zugriffsschlüssel-ID, einem geheimen Zugriffsschlüssel und einem Sitzungstoken bestehen. Die Identity Broker-Anwendung stellt diese temporären Sicherheitsanmeldeinformationen der internen Unternehmensanwendung zur Verfügung. Die Anwendung kann dann die temporären Anmeldeinformationen für direkte Aufrufe an AWS verwenden. Die Anwendung speichert die Anmeldeinformationen bis zum Ablaufdatum zwischen und fordert dann einen neuen Satz temporärer Anmeldeinformationen an. Die folgende Abbildung veranschaulicht dieses Szenario.

Beispiel für einen Workflow mit einer benutzerdefinierten Identity Broker-Anwendung

Dieses Szenario hat folgende Attribute:

  • Die Identity Broker-Anwendung ist berechtigt, auf den Token-Service (STS) zuzugreifen IAMAPI, um temporäre Sicherheitsanmeldeinformationen zu erstellen.

  • Die Identity Broker-Anwendung kann überprüfen, ob die Mitarbeiter im vorhandenen Authentifizierungssystem authentifiziert sind.

  • Benutzer können eine temporäre Datei erhaltenURL, die ihnen Zugriff auf die AWS Management Console gewährt (was als Single Sign-On bezeichnet wird).

Weitere Informationen zum Erstellen von temporären Sicherheitsanmeldeinformationen finden Sie unter AWS STS Referenzen vergleichen. Weitere Informationen zu Verbundbenutzern, die Zugriff auf die AWS Management Console erhalten, finden Sie unter. Aktivieren des Zugriffs von SAML 2.0-Verbundbenutzern auf AWS Management Console