Verwenden des SAML-basierten Verbunds für API-Zugriff auf AWS Überblick über die Konfiguration des SAML 2.0-basierten Verbunds Übersicht über die Rolle, um Federated-SAML-Zugriff auf Ihre AWS-Ressourcen zuzulassen Eindeutige Identifizierung von Benutzern im SAML-basierten Verbund

Informationen zum SAML 2.0-basierten Verbund

AWS unterstützt den Identitätsverbund mit SAML 2.0 (Security Assertion Markup Language 2.0), einem offenen Standard, den viele Identitätsanbieter verwenden. Dieses Feature ermöglicht verbundenes Single Sign-On (SSO), sodass Benutzer sich bei der AWS Management Console anmelden oder die AWS-API-Operationen aufrufen können, ohne dass Sie einen IAM-Benutzer für jedes Mitglied der Organisation erstellen müssen. Durch die Verwendung von SAML lässt sich das Konfigurieren des Verbunds mit AWS vereinfachen, da Sie den Service des Identitätsanbieters verwenden können, anstatt benutzerdefinierten Identitäts-Proxy-Code zu schreiben.

Der IAM-Verbund unterstützt die folgenden Anwendungsfälle:

Federated-Zugriff, um einem Benutzer oder einer Anwendung in der Organisation das Aufrufen von AWS-API-Operationen zu gestatten. Sie verwenden eine SAML-Zusicherung (als Teil der Authentifizierungsantwort), die in Ihrer Organisation generiert wird, um temporäre Sicherheitsanmeldeinformationen zu erhalten. Dieses Szenario ähnelt anderen Verbund-Szenarien, die von IAM unterstützt werden, wie diejenigen, die in Anfordern temporärer Sicherheitsanmeldeinformationen und Über Web-Identitätsverbund beschrieben werden. Allerdings bewältigen SAML 2.0-basierte Identitätsanbieter in Ihrer Organisation viele der Details zur Laufzeit, um die Authentifizierung und Autorisierung zu überprüfen. Dies ist das Szenario, das in diesem Thema besprochen wird.
Webbasiertes Single Sign-On (SSO) an der AWS Management Console aus Ihrer Organisation. Benutzer können sich bei einem Portal in Ihrer Organisation anmelden, das von einem SAML 2.0 kompatiblen Identitätsanbieter gehostet wird, eine Option auswählen, um zu AWS zu wechseln, und ohne zusätzliche Anmeldeinformationen an die Konsole weitergeleitet werden. Sie können außerdem einen SAML-Identitätsanbieter eines Drittanbieters verwenden, um SSO-Zugriff auf die Konsole zu erhalten. Oder Sie können einen benutzerdefinierten Identitätsanbieter erstellen, um externen Benutzern Zugriff auf die Konsole zu gewähren. Weitere Informationen zum Erstellen eines benutzerdefinierten Identitätsanbieters finden Sie unter Aktivieren von benutzerdefiniertem Identity Broker-Zugriff auf die AWS-Konsole.

Themen

Verwenden des SAML-basierten Verbunds für API-Zugriff auf AWS
Überblick über die Konfiguration des SAML 2.0-basierten Verbunds
Übersicht über die Rolle, um Federated-SAML-Zugriff auf Ihre AWS-Ressourcen zuzulassen
Eindeutige Identifizierung von Benutzern im SAML-basierten Verbund

Verwenden des SAML-basierten Verbunds für API-Zugriff auf AWS

Gehen wir davon aus, Sie möchten Mitarbeitern die Möglichkeit bieten, Daten von ihren Computern in einen Sicherungsordner zu kopieren. Sie erstellen eine Anwendung, die Benutzer auf ihrem Computer ausführen können. Im Backend liest und schreibt die Anwendung Objekte in einem S3-Bucket. Benutzer haben keinen direkten Zugriff auf AWS. Stattdessen wird der folgende Prozess verwendet:

Abrufen temporärer Sicherheitsanmeldeinformationen basierend auf einer SAML-Zusicherung

Ein Benutzer in Ihrer Organisation verwendet eine Client-App, um eine Authentifizierung vom Identitätsanbieter Ihrer Organisation anzufordern.
Der Identitätsanbieter authentifiziert den Benutzer anhand des Identitätsspeichers Ihrer Organisation.
Der Identitätsanbieter konstruiert eine SAML-Zusicherung mit Informationen über den Benutzer und sendet die Zusicherung an die Client-App.
Die Client-App ruft die AWS STS-AssumeRoleWithSAML-API auf und übergibt die ARN des SAML-Anbieters, die ARN der zu übernehmenden Rolle und die SAML-Zusicherung vom Identitätsanbieter.
Die API-Antwort an die Client-App umfasst temporäre Sicherheitsanmeldeinformationen.
Die Client-App verwendet die temporären Sicherheitsanmeldeinformationen, um Amazon S3-API-Operationen aufzurufen.

Überblick über die Konfiguration des SAML 2.0-basierten Verbunds

Bevor Sie den SAML 2.0-basierten Verbund wie im vorhergehenden Szenario und Diagramm beschrieben verwenden können, müssen Sie den Identitätsanbieter Ihrer Organisation und Ihr AWS-Konto so konfigurieren, dass sie sich gegenseitig vertrauen. Der allgemeine Prozess für die Konfiguration dieses Vertrauens wird in den folgenden Schritten beschrieben. Innerhalb Ihrer Organisation müssen Sie einen Identitätsanbieter haben, der SAML 2.0 unterstützt, wie Microsoft Active Directory Federation Service (AD FS, Teil von Windows Server), Shibboleth oder einen anderen kompatiblen SAML 2.0-Anbieter.

Anmerkung

Um die Verbundstabilität zu verbessern, empfehlen wir, dass Sie Ihren IdP und Ihren AWS-Verbund so konfigurieren, dass mehrere SAML-Anmeldeendpunkte unterstützt werden. Einzelheiten finden Sie im AWS-Sicherheitsblogartikel How to use regional SAML endpoints for failover.

So konfigurieren Sie den Identitätsanbieter und AWS so, dass sie sich gegenseitig vertrauen

Registrieren Sie AWS als Serviceanbieter (SP) bei dem Identitätsanbieter Ihrer Organisation. Verwenden Sie das SAML-Metadatendokument von https://region-code.signin.aws.amazon.com/static/saml-metadata.xml

Eine Liste möglicher Werte für region-code finden Sie in der Spalte Region unter AWS Sign-In endpoints (-Anmelde-Endpunkte).

Optional können Sie das SAML-Metadatendokument von https://signin.aws.amazon.com/static/saml-metadata.xml verwenden.
Mithilfe des Identitätsanbieters Ihrer Organisation erstellen Sie eine entsprechende Metadaten-XML-Datei, die Ihren Identitätsanbieter als IAM-Identitätsanbieter in AWS beschreibt. Sie muss den Aussteller-Namen, ein Erstellungsdatum, ein Ablaufdatum und Schlüssel enthalten, die AWS verwenden kann, um Authentifizierungsantworten (Zusicherungen) von Ihrer Organisation zu überprüfen.
In der IAM-Konsole erstellen Sie eine SAML-Identitätsanbietereinheit. Laden Sie in diesem Prozess das SAML-Metadaten-Dokument hoch, das vom Identitätsanbieter Ihrer Organisation in Schritt 2 erstellt wurde. Weitere Informationen finden Sie unter Erstellen von IAM-SAML-Identitätsanbietern.
In IAM erstellen Sie eine oder mehrere IAM-Rollen. In der Vertrauensrichtlinie der Rolle legen Sie den SAML-Anbieter als Auftraggeber fest, der eine Vertrauensbeziehung zwischen Ihrer Organisation und herstellt AWS. Die Berechtigungsrichtlinie der Rolle legt fest, wozu die Benutzer in Ihrer Organisation in AWS berechtigt sind. Weitere Informationen finden Sie unter Erstellen von Rollen für externe Identitätsanbieter (Verbund).

Anmerkung
SAML-IDPs, die in einer Rollen-Vertrauensrichtlinie verwendet werden, müssen sich in demselben Konto befinden, in dem sich die Rolle befindet.
Im Identitätsanbieter Ihrer Organisation definieren Sie Zusicherungen, in denen Benutzer oder Gruppen in Ihrer Organisation den IAM-Rollen zugeordnet werden. Beachten Sie, dass unterschiedliche Benutzer und Gruppen in Ihrer Organisation unterschiedlichen IAM-Rollen zugeordnet werden können. Die genauen Schritte zur Durchführung des Mappings hängen davon ab, welche Identitätsanbieter Sie verwenden. Im früheren Szenario eines Amazon S3-Ordners für Benutzer ist es möglich, dass alle Benutzer derselben Rolle zugeordnet werden, die Amazon S3-Berechtigungen bieten. Weitere Informationen finden Sie unter Konfigurieren von SAML-Zusicherungen für die Authentifizierungsantwort.

Wenn Ihr Identitätsanbieter SSO an der AWS-Konsole ermöglicht, können Sie die maximale Dauer der Konsolensitzungen konfigurieren. Weitere Informationen finden Sie unter Aktivieren von Zugriff auf die für SAML-2.0-Verbundbenutzer AWS Management Console.

Anmerkung
Die AWS-Implementierung des SAML 2.0-Verbunds unterstützt keine verschlüsselten SAML-Zusicherungen zwischen dem IAM-Identitätsanbieter und AWS. Der Datenverkehr zwischen dem System des Kunden und AWS wird jedoch über einen verschlüsselten (TLS-)Kanal übertragen.
In der Anwendung, die Sie erstellen, rufen Sie die AWS Security Token Service-AssumeRoleWithSAML-API auf, übergeben die ARN des SAML-Anbieters, die Sie in Schritt 3 erstellt haben, die ARN der zu übernehmenden Rolle, die Sie in Schritt 4 erstellt haben, und die SAML-Zusicherung über den aktuellen Benutzer, die Sie von Ihrem Identitätsanbieter erhalten. AWS stellt sicher, dass die Anforderung zur Übernahme der Rolle vom Identitätsanbieter kommt, auf den im SAML-Provider verwiesen wird.

Weitere Informationen finden Sie unter AssumeRoleWithSAML in der AWS Security Token Service-API-Referenz.
Wenn die Anforderung erfolgreich ist, gibt die API eine Reihe temporärer Sicherheitsanmeldeinformationen zurück, die Ihre Anwendung verwenden kann, um signierte Anforderungen an AWS zu stellen. Ihre Anwendung hat Informationen über den aktuellen Benutzer und kann auf benutzerspezifische Ordner in Amazon S3 zugreifen, wie im vorherigen Szenario beschrieben.

Übersicht über die Rolle, um Federated-SAML-Zugriff auf Ihre AWS-Ressourcen zuzulassen

Die Rolle oder Rollen, die Sie in IAM erstellen, definieren, wozu Verbundbenutzer aus Ihrer Organisation in berechtigt sind AWS. Beim Erstellen der Vertrauensrichtlinie für die Rolle geben Sie den SAML-Anbieter an, die Sie zuvor als Principal erstellt haben. Darüber hinaus können Sie den Geltungsbereich der Vertrauensrichtlinie mithilfe einer Condition festlegen, sodass nur Benutzer, die bestimmte SAML-Attribute erfüllen, auf die Rolle zugreifen können. Sie können beispielsweise festlegen, dass nur Benutzer, deren SAML-Zugehörigkeit staff lautet (wie von https://openidp.feide.no bestätigt), Zugriff auf die Rolle haben, wie in der folgenden Musterrichtlinie gezeigt:


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Federated": "arn:aws:iam::account-id:saml-provider/ExampleOrgSSOProvider"},
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {
      "StringEquals": {
        "saml:aud": "https://signin.aws.amazon.com/saml",
        "saml:iss": "https://openidp.feide.no"
      },
      "ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]}
    }
  }]
}

Anmerkung

SAML-IDPs, die in einer Rollen-Vertrauensrichtlinie verwendet werden, müssen sich in demselben Konto befinden, in dem sich die Rolle befindet.

Weitere Informationen zu den SAML-Schlüsseln, die Sie in einer Richtlinie überprüfen können, finden Sie unter Verfügbare Schlüssel für SAML-basierten AWS STS-Verbund.

Sie können unter https://region-code.signin.aws.amazon.com/static/saml-metadata.xml regionale Endpunkte für das saml:aud-Attribut einfügen. Eine Liste möglicher Werte für region-code finden Sie in der Spalte Region unter AWS Sign-In endpoints (-Anmelde-Endpunkte).

Für die Berechtigungsrichtlinie in der Rolle geben Sie Berechtigungen wie bei jeder anderen Rolle auch an. Wenn Benutzer aus Ihrer Organisation zum Beispiel Amazon Elastic Compute Cloud-Instances verwalten dürfen, müssen Sie Amazon EC2-Aktionen in der Berechtigungsrichtlinie explizit zulassen, z. B. solche in der AmazonEC2FullAccess verwalteten Richtlinie.

Eindeutige Identifizierung von Benutzern im SAML-basierten Verbund

Wenn Sie Zugriffsrichtlinien in IAM erstellen können, ist es häufig nützlich, wenn Berechtigungen basierend auf der Identität der Benutzer angegeben werden können. Für Benutzer, die mit SAML verbunden wurde, möchte eine Anwendung möglicherweise Informationen in Amazon S3 mit einer Struktur wie dieser behalten:


myBucket/app1/user1
myBucket/app1/user2
myBucket/app1/user3

Sie können den Bucket (myBucket) und Ordner (app1) über die Amazon S3-Konsole oder die AWS CLI erstellen, da diese statische Werte sind. Die benutzerspezifischen Ordner (user1, user2, user3 etc.) müssen jedoch mithilfe von Code zur Laufzeit erstellt werden, da der Wert, der den Benutzer identifiziert, erst bekannt wird, wenn sich der Benutzer das erste Mal über den Verbundprozess anmeldet.

Um Richtlinien zu schreiben, die auf benutzerspezifische Details als Teil eines Ressourcennamens verweisen, muss die Identität des Benutzers in SAML-Schlüsseln verfügbar sein, die in Richtlinienbedingungen verwendet werden können. Die folgenden Schlüssel sind für SAML 2.0-basierten Verbund zur Verwendung in IAM-Richtlinien verfügbar. Sie können die von den folgenden Schlüsseln zurückgegebenen Werte verwenden, um eindeutige Benutzerkennungen für Ressourcen wie Amazon S3-Ordner zu erstellen.

saml:namequalifier. Ein Hash-Wert basierend auf der Verkettung des Issuer-Antwortwerts (saml:iss) und einer Zeichenfolge mit der AWS-Konto-ID und dem Anzeigenamen (der letzte Teil der ARN) des SAML-Anbieters in IAM. Die Verkettung der Konto-ID und des Anzeigenamens des SAML-Anbieters steht als der Schlüssel saml:doc für IAM-Richtlinien zur Verfügung. Die Konto-ID und der Name des Anbieters müssen durch ein '/' getrennt werden, wie in "123456789012/anbieter_name". Weitere Informationen finden Sie im saml:doc-Schlüssel unter Verfügbare Schlüssel für SAML-basierten AWS STS-Verbund.

Die Kombination aus NameQualifier und Subject kann verwendet werden, um einen Verbundbenutzer eindeutig zu identifizieren. Die folgende Pseudocode zeigt, wie dieser Wert berechnet wird. In diesem Pseudocode bedeutet + eine Verkettung, SHA1 stellt eine Funktion dar, die einen Nachrichtendigest mit SHA-1 produziert, und Base64 stellt eine Funktion dar, die eine Base-64-codierte Version der Hash-Ausgabe produziert.

Base64 ( SHA1 ( "https://example.com/saml" + "123456789012" + "/MySAMLIdP" ) )

Weitere Informationen über die Richtlinienschlüssel, die für den SAML-Verbund verfügbar sind, finden Sie unter Verfügbare Schlüssel für SAML-basierten AWS STS-Verbund.
saml:sub (string). Dies ist der Betreff des Antrags, der einen Wert enthält, der einen einzelnen Benutzer innerhalb einer Organisation eindeutig identifiziert (zum Beispiel _cbb88bf52c2510eabe00c1642d4643f41430fe25e3).
saml:sub_type (string). Dieser Schlüssel kann persistent, transientoder die vollständige Format-URI aus den Subject- und NameID-Elementen sein, die in Ihrer SAML-Zusicherung verwendet wurden. Der Wert persistent gibt an, dass der Wert in saml:sub für einen Benutzer derselbe für alle Sessions ist. Wenn der Wert transient lautet, hat der Benutzer einen anderen saml:sub-Wert für jede Sitzung. Weitere Informationen zum NameID-Attribut des Format-Elements finden Sie unter Konfigurieren von SAML-Zusicherungen für die Authentifizierungsantwort.

Das folgende Beispiel zeigt eine Berechtigungsrichtlinie, die die oben genannten Schlüssel verwendet, um Berechtigungen für einen benutzerspezifischen Ordner in Amazon S3 zu gewähren. Die Richtlinie geht davon aus, dass die Amazon S3-Objekte mit einem Präfix identifiziert werden, das sowohl saml:namequalifier als auch saml:sub enthält. Beachten Sie, dass das Condition-Element einen Test umfasst, um sicherzustellen, dass saml:sub_type auf persistent festgelegt ist. Wenn er auf transient festgelegt ist, kann der saml:sub-Wert für den Benutzer für jede Sitzung unterschiedlich sein und die Kombination der Werte sollte nicht verwendet werden, um benutzerspezifische Ordner zu identifizieren.


{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": [
      "arn:aws:s3:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws:s3:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}/*"
    ],
    "Condition": {"StringEquals": {"saml:sub_type": "persistent"}}
  }
}

Weitere Informationen zum Mapping von Zusicherungen aus dem Identitätsanbieter zu Richtlinienschlüsseln finden Sie unter Konfigurieren von SAML-Zusicherungen für die Authentifizierungsantwort.

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Weitere Ressourcen für den Web-Identitätsverbund

Erstellen von IAM-Identitätsanbietern