SAML 2.0-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 Single Sign-On (SSO) für den Verbund, sodass sich Benutzer bei der AWS-Managementkonsole anmelden oder AWS-API-Operationen aufrufen können, ohne dass Sie für jeden in Ihrer Organisation einen IAM-Benutzer 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:

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 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 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.

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

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 erstellt haben Principal. 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:

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://ap-east-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 die Verwendung von regionalen Endpunkten anstelle des globalen Endpunkts, um die Ausfallsicherheit des Verbunds zu verbessern. Wenn Sie nur einen Endpunkt konfiguriert haben, können Sie sich in dem unwahrscheinlichen Fall, dass der Endpunkt nicht verfügbar ist, nicht im Verbund mit AWS verbinden. Eine Liste möglicher Werte für region-code finden Sie in der Spalte Region unter AWS Sign-In endpoints (-Anmelde-Endpunkte).

Das folgende Beispiel veranschaulicht das Format der Anmelde-URL mit dem optionalen 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 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.

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.

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:

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 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.

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.