SAML联邦

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

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

• 同盟存取可讓組織中的使用者或應用程式呼叫 AWS API作業。本使用案例將在下一節中討論。您可以使用在組織中產生的SAML宣告 (做為驗證回應的一部分) 來取得暫時的安全性登入資料。此案例類似於其他IAM支援的同盟案例，如請求暫時性安全憑證和中所述OIDC 聯盟。不過，您組織SAML中的 2.0 架構會 IdPs 在執行階段處理許多詳細資料，以便執行驗證和授權檢查。

• AWS Management Console 從您的組織進行 Web 式單一登入 (SSO)。使用者可以登入組織中由 SAML 2.0 相容 IdP 所代管的入口網站、選取要移至的選項，然後重新導向至主控台 AWS，而不需要提供其他登入資訊。您可以使用協力廠商 SAML IdP 來建立主控台的SSO存取權，也可以建立自訂 IdP 來為外部使用者啟用主控台存取權。如需有關建構自訂 IdP 的詳細資訊，請參閱 啟用自訂身分識別代理存取主 AWS 控台。

主題

• 使用SAML以基礎的聯合來API存取 AWS
• 設定SAML以 2.0 為基礎的聯合概觀
• 允許SAML同盟存取資源的角色概觀 AWS
• 以唯一方式識別以聯盟SAML為基礎
• 在中建立SAML身分識別提供者 IAM
• 使用信賴方信任和新增宣告來設定您的 SAML 2.0 IdP
• 將第三方 SAML 解決方案提供者與 AWS
• 設定驗證回SAML應的宣告
• 啟用 SAML 2.0 聯合身分的使用者存取 AWS Management Console
• 在瀏覽器中檢視SAML回應

使用SAML以基礎的聯合來API存取 AWS

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

1. 組織中的使用者會使用用戶端應用程式來請求獲得組織 IdP 的身分驗證。

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

3. IdP 構造一個SAML斷言與有關用戶的信息，並將斷言發送到客戶端應用程序。

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

5. 對客戶端API應用程序的響應包括臨時安全憑據。

6. 用戶端應用程式使用臨時安全登入資料呼叫 Amazon S3 API 操作。

設定SAML以 2.0 為基礎的聯合概觀

您必須先 AWS 帳戶 將組織的 IdP 設定為彼此信任，然後才能使用以 SAML 2.0 為基礎的聯合，如前述案例和圖表所述。以下步驟介紹了用於配置此信任關係的一般過程。在您的組織中，您必須有支援 SAML 2.0 的 IdP，例如 Microsoft 作用中目錄同盟服務 (AD FS，Windows 伺服器的一部分)、Shibboleth 或其他相容的 2.0 提供者。SAML

注意

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

設定組織的 IdP 並互 AWS 相信任

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

   對於可能的列表 region-code 值，請參閱AWS 登入端點中的 [區域] 欄。

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

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

3. 在IAM主控台中，您可以建立SAML身分識別提供者。在此程序中，您會上傳中SAML繼資料文件，這些金鑰是由中組織中的 IdP 所產生的。步驟 2如需詳細資訊，請參閱在中建立SAML身分識別提供者 IAM。

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

   注意

   SAMLIDPs在角色信任策略中使用的帳戶必須與角色所在的帳戶相同。

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

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

6. 在您建立的應用程式中，呼叫 AWS Security Token Service AssumeRoleWithSAMLAPI、傳遞您建立ARN的SAML提供者步驟 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。此外，您還可以使用 a 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"]}
    }
  }]
}

注意

SAMLIDPs在角色信任策略中使用的帳戶必須與角色所在的帳戶相同。

如需可簽入原則之SAML金鑰的詳細資訊，請參閱SAML以 AWS STS 聯合為基礎的可用金鑰。

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

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

以唯一方式識別以聯盟SAML為基礎

在中建立存取原則時IAM，能夠根據使用者的身分指定權限通常很有用。例如，對於已經使用聯合身分的使用者SAML，應用程式可能想要使用這樣的結構將資訊保留在 Amazon S3 中：

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

您可以透過 Amazon S3 主控台或建立儲存貯體 (myBucketapp1) 和資料夾 () AWS CLI，因為這些都是靜態值。但是，用戶特定的文件夾（user1, user2, user3等） 必須在執行時使用程式碼來建立，因為在使用者首次透過聯合身分流程登入之前，用來辨識使用者的值是未知的。

若要撰寫參考使用者特定詳細資料做為資源名稱一部分的策略，使用者識別必須在可用於原則條件的SAML金鑰中提供。下列機碼適用於以 SAML 2.0 為基礎的聯合，以便在原則中IAM使用。您可以使用以下索引鍵傳回的值為資源 (如 Amazon S3 資料夾) 建立唯一的使用者識別碼。

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

  NameQualifier 與 Subject 的組合可用於單獨辨識聯合身分使用者。下列虛擬程式碼顯示這個值是如何計算出來的。在此偽代碼表+示連接，SHA1表示使用 SHA -1 產生消息摘要的函數，並Base64表示產生哈希輸出 Base-64 編碼版本的函數。

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

  如需有關可用於SAML以聯合為基礎的原則金鑰的詳細資訊，請參閱SAML以 AWS STS 聯合為基礎的可用金鑰。

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

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

以下範例顯示了一個許可政策，該政策使用上述索引鍵為 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:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws:s3:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}/*"
    ],
    "Condition": {"StringEquals": {"saml:sub_type": "persistent"}}
  }
}

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