SAML 2.0 聯合身分

AWS 使用 SAML 2.0 (安全性聲明標記語言 2.0) 支援聯合身分，而 SAML 2.0 是許多身分提供者 (IdP) 採用的一種開放標準。此功能可啟用聯合單一登入 (SSO)，因此使用者可以登入 AWS Management Console或呼叫 AWS API 操作，而不必為組織中的每個人都建立一個 IAM 使用者。由於可以使用 IdP 的服務而不必編寫自訂身分代理程式碼，因此您可以使用 SAML 來簡化為 AWS 配置聯合身分驗證的過程。

IAM 聯合身分支援這些使用案例：

使用以 SAML 為基礎的聯合身分來對 AWS 進行 API 存取

假設您想要為員工提供一種方式，使其能將資料從他們的電腦中複製到備份資料夾。您可以建構一個可在使用者的電腦上執行的應用程式。該應用程式可在後端的 Amazon S3 儲存貯體中讀寫物件。使用者沒有直接存取 AWS 的許可。而應使用以下程序：

配置以 SAML 2.0 為基礎的聯合身分驗證的概觀

在使用前面方案和圖表中所述的以 SAML 2.0 為基礎的聯合身分驗證之前，您必須先配置組織的 IdP 和您的 AWS 帳戶，使之相互信任。以下步驟介紹了用於配置此信任關係的一般過程。組織內部必須有支援 SAML 2.0 的 IdP，例如 Microsoft Active Directory Federation Service (AD FS，Windows Server 的一部分)、Shibboleth 或其他相容的 SAML 2.0 提供者。

用於允許對 AWS 資源進行 SAML 聯合身分存取的角色的概觀

您在 IAM 中建立的一或多個角色可定義組織中允許在 AWS 中執行操作的聯合身分使用者。當您為角色建立信任政策時，您可以將先前建立的 SAML 提供者指定為 Principal。此外，您還可以使用 Condition 設定信任政策的範圍，以便僅允許與特定 SAML 屬性相符的使用者存取角色。例如，您可以指定僅允許 SAML 從屬關係為 staff (在 https://openidp.feide.no 中聲明) 的使用者存取角色，如以下範例政策所示：

{
  "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"]}
    }
  }]
}

如需有關您可以在政策中簽署的 SAML 索引鍵的詳細資訊，請參閱 SAML AWS STS 聯合身分的可用鍵。

您可以包括位於 https://region-code.signin.aws.amazon.com/static/saml-metadata.xml 的 saml:aud 屬性的區域端點。對於可能的 region-code 值清單，請參閱 AWS 登入端點中的 Region (區域) 欄位。

對於該角色中的許可政策，您可以像任何角色一樣指定許可。例如，如果允許您組織的使用者管理 Amazon Elastic Compute Cloud 執行個體，您必須在許可政策中明確允許 Amazon EC2 動作 (例如 AmazonEC2FullAccess 受管政策中的動作)。

單獨辨識以 SAML 為基礎的聯合身分中的使用者

在 IAM 中建立存取政策時，可根據使用者的身分指定許可，這一點通常很有用。舉例來說，對於已使用 SAML 聯合身分的使用者，應用程式可能希望使用如下的結構保留 Amazon S3 中的資訊：

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

您可以透過 Amazon S3 主控台或 AWS CLI 建立儲存貯體 (amzn-s3-demo-bucket) 和資料夾 (app1)，因為這些都是靜態值。不過，使用者特定的資料夾 (user1、user2、user3 等等) 必須在執行階段使用程式碼建立，因為在使用者首次透過聯合身分程序登入時，用來識別使用者的值未知。

若要編寫在資源名稱中引用特定於使用者的詳細資訊的政策，必須在可以用於政策條件的 SAML 索引鍵中提供使用者身分。以下索引鍵可供以 SAML 2.0 為基礎的聯合身分在 IAM 政策中使用。您可以使用以下索引鍵傳回的值為資源 (如 Amazon S3 資料夾) 建立唯一的使用者識別碼。

以下範例顯示了一個許可政策，該政策使用上述索引鍵為 Amazon S3 中的使用者特定資料夾授予許可。該政策假設 Amazon S3 物件使用同時包含 saml:namequalifier 與 saml:sub 的字首識別。請注意，Condition 元素包括一個測試，用於確保 saml:sub_type 設為 persistent。如果已設為 transient，每個工作階段使用者的 saml:sub 值可能不同，因此不應使用值的組合來辨識使用者特定的資料夾。

{
  "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"}}
  }
}

如需有關從 IdP 映射聲明到政策索引鍵的詳細資訊，請參閱 為身分驗證回應設定 SAML 聲明。