SAML 2.0 聯合身分 - AWS Identity and Access Management

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

SAML 2.0 聯合身分

AWS 支援與 SAML 2.0 (安全性宣告標記語言 2.0) 聯合身分識別,這是許多身分識別提供者 (IdPs) 使用的開放標準。此功能可啟用聯合單一登入 (SSO),因此使用者可以登入 AWS Management Console 或呼叫 AWS API 作業,而不必為組織中的每個人建立 IAM 使用者。透過使用 SAML,您可以簡化設定聯合的程序 AWS,因為您可以使用 IdP 的服務,而不需要撰寫自訂身分識別 Proxy 程式碼。

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

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

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


        根據 SAML 聲明取得暫時安全憑證
  1. 組織中的使用者會使用用戶端應用程式來請求獲得組織 IdP 的身分驗證。

  2. IdP 根據組織的身分存放區對使用者進行身分驗證。

  3. IdP 會建構一個具有使用者相關資訊的 SAML 聲明,並將此聲明發送到用戶端應用程式。

  4. 用戶端應用程式會呼叫 AWS STS AssumeRoleWithSAMLAPI、傳遞 SAML 提供者的 ARN、要承擔之角色的 ARN,以及來自 IdP 的 SAML 宣告。

  5. API 對用戶端應用程式的回應包括臨時性安全憑證。

  6. 用戶端應用程式使用臨時安全性憑證來呼叫 Amazon S3 API 操作。

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

您必須先設定組織的 IdP 和彼此信任,才能如前述案例和圖表中所述使用 SAML 2.0 型聯合。 AWS 帳戶 以下步驟介紹了用於配置此信任關係的一般過程。組織內部必須有支援 SAML 2.0 的 IdP,例如 Microsoft Active Directory Federation Service (AD FS,Windows Server 的一部分)、Shibboleth 或其他相容的 SAML 2.0 提供者。

注意

若要改善聯合彈性,建議您將 IdP 和 AWS 聯合設定為支援多個 SAML 登入端點。如需詳細資訊,請參閱 AWS 安全性部落格文章如何使用地區性 SAML 端點進行容錯移轉

若要設定組織的 IdP 並 AWS 彼此信任
  1. 向您組織的 IdP 註冊 AWS 為服務提供者 (SP)。使用 https://region-code.signin.aws.amazon.com/static/saml-metadata.xml 中的 SAML 中繼資料文件

    對於可能的 region-code 值清單,請參閱 AWS 登入端點中的 Region (區域) 欄位。

    您可以選擇性地使用 https://signin.aws.amazon.com/static/saml-metadata.xml 中的 SAML 中繼資料文件。

  2. 使用您組織的 IdP 時,您會產生一個同等中繼資料 XML 檔,該檔案可將您的 IdP 描述為 AWS中的 IAM 身分提供者。它必須包含發行者名稱、建立日期、到期日,以及 AWS 可用來驗證組織的驗證回應 (宣告) 的金鑰。

  3. 在 IAM 主控台中,您可以建立一個 SAML 身分供應者實體。在此過程中,您將上傳由組織的 IdP 在 步驟 2 中產生的 SAML 中繼資料文件。如需詳細資訊,請參閱 在 IAM 中建立 SAML 身分識別提供者

  4. 在 IAM 中,建立一或多個 IAM 角色。在角色的信任原則中,您可以將 SAML 提供者設定為主參與者,以便在您的組織與 AWS. 該角色的許可政策將決定允許您組織的使用者在 AWS中執行的操作。如需詳細資訊,請參閱 針對第三方身分提供者建立角色 (聯合身分)

    注意

    角色信任政策中使用的 SAML IDP 必須與角色所在的帳戶相同。

  5. 在您組織的 IdP 中,定義可將組織中的使用者或群組映射到 IAM 角色的聲明。請注意,組織中不同的使用者和群組可能映射到不同的 IAM 角色。執行映射的確切步驟取決於您使用的 IdP。在使用者的 Amazon S3 資料夾的早期方案中,可能出現所有使用者映射到提供 Amazon S3 許可的同一角色的情況。如需詳細資訊,請參閱 設定驗證回應的 SAML 宣告

    如果您的 IdP 對 AWS 主控台啟用 SSO,則您可以設定主控台工作階段的持續時間上限。如需詳細資訊,請參閱 使 SAML 2.0 聯合身分使用者能夠存取 AWS Management Console

    注意

    AWS 實作 SAML 2.0 聯合不支援 IAM 身分識別提供者與之間的加密 SAML 宣告。 AWS不過,客戶系統之間的流量 AWS 會透過加密 (TLS) 通道傳輸。

  6. 在您建立的應用程式中,呼叫 AWS Security Token Service AssumeRoleWithSAML API,將您建立的 SAML 提供者的 ARN 傳遞給它步驟 3、假設您在其中建立的角色 ARN,以及您從 IdP 取得之目前使用者的 SAML 宣告。步驟 4 AWS 確保假定角色的請求來自 SAML 提供者中參考的 IdP。

    如需詳細資訊,請參閱 AWS Security Token Service API 參考資料中的 AssumeRoleWithSAML

  7. 如果請求成功,API 會傳回一組臨時安全性憑證,您的應用程式即可用其向 AWS發出已簽署的請求。您的應用程式具有有關目前使用者的資訊並可存取 Amazon S3 中使用者特定的資料夾,如上一方案中所述。

允許 SAML 聯合存取資源的角色概觀 AWS

您在 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 IDP 必須與角色所在的帳戶相同。

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

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

對於該角色中的許可政策,您可以像任何角色一樣指定許可。例如,如果允許組織中的使用者管理 Amazon 彈性運算雲端執行個體,您必須在許可政策中明確允許 Amazon EC2 動作,例如 AmazonEC2 FullAccess 受管政策中的動作。

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

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

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

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

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

  • saml:namequalifier. 雜湊值,以 Issuer 回應值 (saml:iss)、含 AWS 帳戶 ID 的字串與 IAM 中 SAML 提供者的易記名稱 (ARN 的最後一部分) 的串聯為基礎。帳戶 ID 與 SAML 提供者的易記名稱的串聯可作為索引鍵 saml:doc 供 IAM 政策使用。帳戶 ID 與提供者名稱必須使用「/」分隔,例如「123456789012/provider_name」。如需詳細資訊,請參閱 saml:doc 中的 SAML AWS STS 聯合身分的可用鍵 索引鍵。

    NameQualifierSubject 的組合可用於單獨辨識聯合身分使用者。下列虛擬程式碼顯示這個值是如何計算出來的。在此虛擬程式碼中,+ 表示串聯,SHA1 代表使用 SHA-1 產生訊息摘要的功能,Base64 64 代表產生雜湊輸出的 Base-64 編碼版本的功能。

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

    如需有關可用於以 SAML 為基礎的聯合身分政策索引鍵的詳細資訊,請參閱 SAML AWS STS 聯合身分的可用鍵

  • saml:sub (string). 這是該陳述的主題,其中包含單獨辨識組織中某個使用者的值 (例如 _cbb88bf52c2510eabe00c1642d4643f41430fe25e3)。

  • saml:sub_type (string). 此索引鍵可以是 persistenttransient 或在您的 SAML 聲明中使用的 FormatSubject 元素的完整 NameID URI。persistent 的值表示在所有工作階段中使用者的 saml:sub 值是相同的。如果值為 transient,則使用者在每個工作階段中擁有不同的 saml:sub 值。如需 NameID 元素的 Format 屬性的詳細資訊,請參閱 設定驗證回應的 SAML 宣告

以下範例顯示了一個許可政策,該政策使用上述索引鍵為 Amazon S3 中的使用者特定資料夾授予許可。該政策假設 Amazon S3 物件使用同時包含 saml:namequalifiersaml: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:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}", "arn:aws:s3:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}/*" ], "Condition": {"StringEquals": {"saml:sub_type": "persistent"}} } }

如需有關從 IdP 映射聲明到政策索引鍵的詳細資訊,請參閱 設定驗證回應的 SAML 宣告