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 für extern authentifizierte Benutzer gewähren (Identitätsverbund)
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, die auf diese Ressourcen zugreifen), benötigen diese Benutzer auch AWS Sicherheitsanmeldeinformationen. Sie können mithilfe einer IAM-Rolle Berechtigungen für Benutzer festlegen, deren Identität in einem Verbund Ihres Unternehmens oder eines externen Identitätsanbieters (IdP) vereinigt ist.
Anmerkung
Als bewährte Sicherheitsmethode empfehlen wir, den Benutzerzugriff in IAM Identity Center mit einem Identitätsverbund zu verwalten, anstatt IAM-Benutzer zu erstellen. Informationen zu bestimmten Situationen, in denen ein IAM-Benutzer erforderlich ist, finden Sie unter Wann sollte ein IAM-Benutzer (anstelle einer Rolle) erstellt werden?.
IAM Identity Center-Berechtigungssätze stellen IAM-Rollenvorlagen bereit, die von IAM Identity Center verwaltet werden. Mit dem Account Access Manager — einer IAM-Funktion — können Sie IAM Identity Center-Benutzern und -Gruppen Ihre eigenen benutzerdefinierten IAM-Rollen zuweisen. Dadurch werden Funktionen wie benutzerdefinierte Vertrauensrichtlinien, Rollentags und konfigurierbare Rollenpfade aktiviert. Sie können es zusammen mit Berechtigungssätzen oder eigenständig verwenden.
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 Sicherheitsanmeldeinformationen, um programmatische Anfragen an diese zu stellen. AWS Für die meisten mobilen Anwendungsszenarien empfehlen wir die Verwendung von Amazon Cognito
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 die meisten Hintergrundarbeiten mit öffentlichen Identitätsanbieterservices für Sie. Es funktioniert mit den gleichen Drittanbieterservices und unterstützt auch anonyme Anmeldungen. Bei anspruchsvolleren Szenarien können Sie jedoch direkt mit einem Drittanbieterservice arbeiten, wie Login with Amazon, Facebook, Google oder einem mit OpenID Connect (OIDC) kompatiblen Identitätsanbieter. Weitere Informationen zur Verwendung des OIDC-Verbunds mithilfe eines dieser Services finden Sie unter OIDC-Verbund.
Vereinigen von Benutzern in einem Verbund mit SAML 2.0
Wenn Ihre Organisation bereits ein Softwarepaket für Identitätsanbieter verwendet, das SAML 2.0 (Security Assertion Markup Language 2.0) unterstützt, können Sie Vertrauen zwischen Ihrer Organisation als Identitätsanbieter (IdP) und als Dienstanbieter herstellen. AWS Anschließend können Sie SAML verwenden, um Ihren Benutzern föderiertes einmaliges Anmelden (SSO) für die AWS-Managementkonsole oder Verbundzugriff zum Aufrufen von API-Vorgängen bereitzustellen. AWS Wenn Ihr Unternehmen beispielsweise Microsoft Active Directory und Active Directory Federation Services verwendet, können Sie dies mit SAML 2 in einem Verbund vereinigen. Weitere Informationen zum Verbund von Benutzern mit SAML 2.0 finden Sie unter SAML 2.0-Föderation.
Vereinigen von Benutzern in einem Verbund durch Erstellen einer benutzerdefinierten Identity Broker-Anwendung
Wenn Ihre Identitätsquelle nicht mit SAML 2.0 kompatibel ist, können Sie eine benutzerdefinierte Identity Broker-Anwendung erstellen, um eine ähnliche Funktion durchzuführen. Die Broker-Anwendung authentifiziert Benutzer, fordert temporäre Anmeldeinformationen für Benutzer von an und stellt sie dem AWS Benutzer dann für den Zugriff auf Ressourcen zur Verfügung. AWS
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 das Beispielunternehmen möchte keinen separaten IAM-Benutzer für jeden Mitarbeiter 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 Mitarbeiter beim vorhandenen Identitäts- und Authentifizierungssystem des Beispielunternehmens angemeldet sind, das möglicherweise LDAP, Active Directory oder ein anderes System nutzt. Die Identity Broker-Anwendung ruft dann die temporären Anmeldeinformationen für die Mitarbeiter ab. Dieses Szenario ähnelt dem vorherigen (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-Operationen finden Sie unter Temporäre IAM Sicherheitsanmeldeinformationen und Berechtigungen für temporäre Sicherheits-Anmeldeinformationen.) 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.
Dieses Szenario hat folgende Attribute:
-
Die Identity Broker-Anwendung hat die Berechtigung, auf die STS-API (Security Token Service) von IAM zuzugreifen, 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 URL abrufen, über die sie auf die AWS Managementkonsole zugreifen können (die als Single Sign-On bezeichnet wird).
Weitere Informationen zum Erstellen von temporären Sicherheitsanmeldeinformationen finden Sie unter AWS STS Referenzen vergleichen. Weitere Informationen dazu, wie SAML-Verbundprinzipale Zugriff auf die AWS Management Console erhalten, finden Sie unter. Aktivieren von SAML 2.0-Verbundprinzipalen für den Zugriff auf AWS-Managementkonsole