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.

SAML 2.0-Föderation

AWS unterstützt den Identitätsverbund mit SAML 2.0 (Security Assertion Markup Language 2.0), einem offenen Standard, den viele Identitätsanbieter (IdPs) verwenden. Diese Funktion ermöglicht Verbund-Single-Sign-On (SSO), sodass sich Benutzer bei den AWS API-Vorgängen anmelden AWS-Managementkonsole oder diese aufrufen können, ohne dass Sie für jeden in Ihrer Organisation einen IAM-Benutzer erstellen müssen. Durch die Verwendung von SAML können Sie die Konfiguration von Federation mit vereinfachen AWS, da Sie den Dienst des IdP verwenden können, anstatt einen benutzerdefinierten Identitätsproxycode zu schreiben.

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

Verwenden Sie den Verbund für den API-Zugriff auf SAML-based 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 Amazon-S3-Bucket. Benutzer haben keinen direkten Zugriff auf AWS. Stattdessen wird der folgende Prozess verwendet:

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

Bevor Sie den SAML 2.0-basierten Verbund verwenden können, wie im vorherigen Szenario und Diagramm beschrieben, müssen Sie den IdP Ihrer Organisation und Sie so konfigurieren, dass sie sich gegenseitig vertrauen. AWS-Konto 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.

Überblick über die Rolle, die den SAML-federated Zugriff auf Ihre ermöglicht AWS Ressourcen

Die Rollen, die Sie in IAM erstellen, definieren, wozu SAML-Verbundprinzipale aus Ihrer Organisation in AWS berechtigt sind. 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 angeben, dass nur Benutzer, deren SAML-Zugehörigkeit staff (wie von bestätigthttps://openidp.feide.no) ist, auf die Rolle zugreifen dürfen, wie in der folgenden Beispielrichtlinie veranschaulicht:

JSON

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

JSON

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

Der Kontextschlüssel saml:aud in der Richtlinie gibt die URL an, die Ihr Browser bei der Anmeldung an der Konsole anzeigt. Diese Anmeldeendpunkt-URL muss mit dem SAML-Empfängerattribut Ihres Identitätsanbieters übereinstimmen. Sie können Anmelde-URLs in bestimmten Regionen angeben. AWS empfiehlt, regionale Endpunkte anstelle des globalen Endpunkts zu verwenden, um die Stabilität des Verbunds zu verbessern. Wenn Sie nur einen Endpunkt konfiguriert haben, können Sie AWS in dem unwahrscheinlichen Fall, dass der Endpunkt nicht verfügbar ist, keinen Verbund herstellen. Eine Liste der möglichen region-code Werte finden Sie in der Spalte Region in AWS Sign-In Endpoints Endpoints.

Das folgende Beispiel zeigt das URL-Format für die Anmeldung mit den optionalen Angaben, die erforderlich sind. region-code

https://region-code.signin.aws.amazon.com/saml

Wenn eine SAML-Verschlüsselung erforderlich ist, muss die Anmelde-URL die eindeutige Kennung enthalten, die AWS Ihrem SAML-Anbieter zuweist. Diese finden Sie auf der Detailseite des Identitätsanbieters. Im folgenden Beispiel enthält die Anmelde-URL eine eindeutige Kennung des Identitätsanbieters, weshalb /acs/ an den Anmeldepfad angefügt werden muss.

https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID

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

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-based AWS STS Verbund.

Eindeutige Identifizierung von Benutzern im Verbund SAML-based

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:

amzn-s3-demo-bucket/app1/user1
amzn-s3-demo-bucket/app1/user2
amzn-s3-demo-bucket/app1/user3

Sie können den Bucket (amzn-s3-demo-bucket) und den Ordner (app1) über die Amazon S3-Konsole oder die erstellen AWS CLI, da es sich um statische Werte handelt. Die benutzerspezifischen Ordner (user1, user2user3, usw.) müssen jedoch zur Laufzeit mithilfe von Code erstellt werden, da der Wert, der den Benutzer identifiziert, erst bekannt ist, wenn sich der Benutzer zum ersten 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.

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.

JSON

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

JSON

{
  "Version":"2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": [
      "arn:aws-cn:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws-cn:s3:::amzn-s3-demo-bucket-org-data/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-Assertionen für die Authentifizierungsreaktion.