本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# IAM 角色的常見案例
與大多數 AWS 功能一樣，您通常有兩種方式可以使用角色：在 IAM 主控台中以互動方式使用，或以程式設計方式使用 AWS CLI、Tools for Windows PowerShell 或 API。
+ 使用 IAM 主控台的帳戶中的 IAM 使用者可以*切換到*角色，以臨時使用主控台中角色的許可。使用者放棄其原始許可並取得指派給該角色的許可。當使用者退出角色時，將恢復其原始許可。
+ AWS （例如 Amazon EC2) 提供的應用程式或服務可以透過請求角色的臨時安全登入資料來*擔任*角色，以便向其發出程式設計請求 AWS。您以這種方式使用角色，這樣您就不必為需要存取資源的每個實體分享或維護長期安全憑證 (例如，透過建立 IAM 使用者)。
**注意**
本指南互換使用*切換到角色*和*擔任角色*字詞。
使用角色的最簡單方法是授予 IAM 使用者切換到您在自己或另一個 AWS 帳戶中建立之角色的許可。他們可以使用 IAM 主控台輕鬆切換角色，以使用您通常不希望他們擁有的許可，然後退出角色以放棄這些許可。這有助於防止*意外*存取或修改敏感資源。
如需角色的更複雜用途，例如授予存取應用程式和服務，或聯合身分外部使用者，您可以呼叫 `AssumeRole` API。這個 API 呼叫會傳回一組臨時憑證，應用程式可以在後續 API 呼叫中使用這些憑證。嘗試使用臨時憑證的動作只能透過相關的角色授予許可。應用程式不需要像主控台中的使用者般「退出」角色；相反，應用程式只是停止使用臨時憑證並繼續使用原始憑證進行呼叫。
聯合身分使用者使用來自身分提供者 (IdP) 的登入資料來登入。 AWS 然後， 會提供暫時登入資料給信任的 IdP，以傳遞給使用者，以便在後續 AWS 資源請求中包含 。這些憑證提供授予指定角色的許可。
本節概述以下案例：
+ [為您擁有的 IAM 使用者提供存取權 AWS 帳戶 ，以存取您擁有的另一個帳戶中的資源](id_roles_common-scenarios_aws-accounts.md)
+ [提供對非 AWS 工作負載的存取權](id_roles_common-scenarios_non-aws.md)
+ [將存取權提供給第三方擁有之 AWS 帳戶 中的 IAM 使用者](id_roles_common-scenarios_third-party.md)
+ [為 AWSAWS 資源提供的服務提供存取權](id_roles_common-scenarios_services.md)
+ [將存取權提供給外部驗證使用者 (聯合身分)](id_roles_common-scenarios_federated-users.md)
# 在您擁有的另一個 IAM 使用者中 AWS 帳戶 存取
您可以授予 IAM 使用者許可，以切換到 內的角色， AWS 帳戶 或切換到 AWS 帳戶 您擁有的其他 中定義的角色。
**注意**
如果要授予對您未擁有或無法控制的帳戶的存取許可，請參閱本主題後面的 [存取第三方 AWS 帳戶 擁有的](id_roles_common-scenarios_third-party.md)。
假設您擁有一個對組織來說至關重要的 Amazon EC2 執行個體。您可以使用這些許可來建立角色，而非直接授予使用者終止執行個體的許可。然後，允許管理員可以在需要終止執行個體時切換為該角色。這麼做，可為執行個體加入以下幾層保護：
+ 您必須向使用者明確授予擔任該角色的許可。
+ 您的使用者必須使用 主動切換到角色， AWS 管理主控台 或使用 AWS CLI 或 AWS API 擔任角色。
+ 您可以為角色加入多重要素驗證 (MFA) 保護，僅限登入 MFA 裝置的使用者才能擔任該角色。若要了解如何配置角色以使擔任角色的使用者必須先使用多重要素驗證 (MFA) 進行身分驗證，請參閱 [透過 MFA 實現安全的 API 存取](id_credentials_mfa_configure-api-require.md)。
我們建議使用此方法強制實施*最低權限*。也就是僅限於特定任務需要時，才能使用升級的許可。藉由角色，您可以幫助防止意外更改敏感環境，如果您將它們與[審核](cloudtrail-integration.md)合併以協助確保僅在需要時才使用角色，將會有極大幫助。
在您出於此目的建立角色時，可在該角色的信任政策的 `Principal` 元素中依照 ID 指定其使用者需要存取許可的帳戶。隨後可以向這些其他帳戶中的特定使用者授予切換到角色的許可。若要了解在您信任區域 (受信任組織或帳戶) 外帳戶中的主體是否具有擔任您角色的許可，請參閱[什麼是 IAM Access Analyzer？](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)。
一個帳戶中的使用者可以切換為相同或不同帳戶中的角色。使用角色過程中，使用者只能執行角色允許的操作並且只能存取角色允許的資源；其原始使用者許可處於暫停狀態。使用者退出角色時，恢復原始使用者許可。
## 使用不同的開發和生產帳戶的範例方案
假設您的組織有多個 AWS 帳戶 來隔離開發環境與生產環境。開發帳戶中的使用者有時可能需要存取生產帳戶中的資源。例如在將更新從開發環境推廣到生產環境時，可能就需要跨帳戶存取許可。儘管您可以為在兩個帳戶中工作的使用者建立單獨的身分 (和密碼)，多個帳戶的憑證管理還是會為身分管理帶來難題。在以下圖表中，所有使用者都透過開發帳戶進行管理，但部分開發人員需要對生產帳戶進行有限存取。開發帳戶有兩個群組：測試人員和開發人員，每個群組有其專屬的政策。
![\[使用角色將許可指派給在不同帳戶中的使用者\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/roles-usingroletodelegate.png)
1. 生產帳戶中的一名管理員使用 IAM 在該帳戶中建立 `UpdateApp` 角色。在角色中，管理員定義信任政策，該政策將開發帳戶指定為 `Principal`，這表示開發帳戶中的授權使用者可以使用 `UpdateApp` 角色。管理員也可以為角色定義許可政策，該政策指定名為 `productionapp` 之 Amazon S3 儲存貯體的讀取和寫入許可。
然後，管理員將與需要擔任角色的任何人共用該角色的帳號和名稱。該資訊是角色的帳號和名稱 （適用於 AWS 主控台使用者） 或 Amazon Resource Name (ARN) （適用於 AWS CLI 或 AWS API 存取）。角色 ARN 類似於 `arn:aws:iam::123456789012:role/UpdateApp`，其中角色名為 `UpdateApp`，而且角色使用帳戶號碼 123456789012 所建立。
**注意**
管理員可以選擇是否配置角色，以便擔任角色的使用者必須先使用多重要素驗證 (MFA) 進行身分驗證。如需詳細資訊，請參閱 [透過 MFA 實現安全的 API 存取](id_credentials_mfa_configure-api-require.md)。
1. 在開發帳戶中，管理員向開發人員群組的成員授予切換為角色的許可。這是透過授予開發人員群組許可來呼叫`UpdateApp`角色的 AWS Security Token Service (AWS STS) `AssumeRole` API 來完成的。開發帳戶中的開發人員群組的所有 IAM 使用者現在都可以切換為生產帳戶中的 `UpdateApp` 角色。不在開發人員群組中的其他使用者無權切換為該角色，因此無法存取生產帳戶中的 S3 儲存貯體。
1. 使用者請求切換為該角色：
+ AWS 主控台：使用者選擇導覽列上的帳戶名稱，然後選擇**切換角色**。使用者指定帳戶 ID (或別名) 和角色名稱。或者，使用者可以按一下管理員在電子郵件中發送的連結。透過該連結，使用者可以前往已填寫詳細資訊的 **Switch Role (切換角色)** 頁面。
+ AWS API/AWS CLI：開發帳戶開發人員群組中的使用者呼叫 `AssumeRole`函數以取得`UpdateApp`角色的登入資料。使用者將 `UpdateApp` 角色的 ARN 指定為呼叫的一部分。如果測試人員群組中的使用者發出相同請求，請求將失敗，因為測試人員沒有針對 `AssumeRole` 角色 ARN 呼叫 `UpdateApp` 的許可。
1. AWS STS 傳回臨時登入資料：
+ AWS console：使用角色的信任政策 AWS STS 驗證請求，以確保請求來自信任的實體 （即開發帳戶）。驗證後， 會將 AWS [臨時安全登入](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html)資料 AWS STS 傳回至 主控台。
+ API/CLI：根據角色的信任政策 AWS STS 驗證請求，以確保請求來自信任的實體 （即開發帳戶）。驗證後， 會 AWS STS 傳回[暫時安全登入](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html)資料給應用程式。
1. 暫時登入資料允許存取 AWS 資源：
+ AWS 主控台： AWS 主控台會代表使用者使用暫時登入資料進行所有後續主控台動作，在此情況下會讀取和寫入儲存`productionapp`貯體。主控台無法存取生產帳戶中的任何其他資源。使用者退出角色時，使用者的許可恢復為切換為角色之前所擁有的原始許可。
+ API/CLI：應用程式使用臨時安全性憑證更新 `productionapp` 儲存貯體。應用程式只能使用臨時安全性憑證讀取和寫入 `productionapp` 儲存貯體，無法存取生產帳戶的任何其他資源。應用程式不必退出角色，只需在後續 API 呼叫中停止使用臨時憑證並使用原始憑證。
## 其他資源
如需詳細資訊，請參閱下列內容：
+ [IAM 教學課程：使用 IAM 角色在 AWS 帳戶之間委派存取權](tutorial_cross-account-with-roles.md)
# 非 AWS 工作負載的存取
[IAM 角色](id_roles.md)是 AWS Identity and Access Management (IAM) 中獲指派[許可](access_policies.md)的物件。當您使用來自 外部的 IAM 身分或身分[擔任該角色](id_roles_manage-assume.md)時 AWS，它會為您的角色工作階段提供暫時安全登入資料。您可能在資料中心或 外部的其他基礎設施中執行工作負載 AWS ，這些工作負載必須存取您的 AWS 資源。您可以使用 AWS Identity and Access Management Roles Anywhere (IAM Roles Anywhere) 驗證非 AWS 工作負載，而不是建立、分發和管理長期存取金鑰。IAM Roles Anywhere 使用來自憑證授權單位 (CA) 的 X.509 憑證來驗證身分 AWS 服務 ，並使用 IAM 角色提供的臨時憑證安全地提供對 的存取。
**若要使用 IAM Roles Anywhere**
1. 使用 [AWS 私有憑證授權單位](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html)設定 CA，或者使用您自己的 PKI 基礎設施中的 CA。
1. 設定 CA 之後，在 IAM Roles Anywhere 中建立稱為*信任錨*的物件。此錨點在 IAM Roles Anywhere 和 CA 之間建立信任，以進行身分驗證。
1. 然後您可以設定現有的 IAM 角色，或建立信任 IAM Roles Anywhere 服務的新角色。
1. 使用信任錨點透過 IAM Roles Anywhere 驗證您的非 AWS 工作負載。 會將非 AWS 工作負載臨時憑證 AWS 授予可存取您 AWS 資源的 IAM 角色。
## 其他資源
下列資源可協助您進一步了解如何提供對非AWS 工作負載的存取權。
+ 如需設定 IAM Roles Anywhere 的詳細資訊，請參閱*《IAM Roles Anywhere 使用者指南》*中的 [What is AWS Identity and Access Management Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) (什麼是 IAM Roles Anywhere)。
+ 若要了解如何為 IAM Roles Anywhere 設定公有金鑰基礎設施 (PKI)，請參閱 *AWS 安全部落格*中的 [IAM Roles Anywhere with an external certificate authority](https://aws.amazon.com/blogs/)。
# 存取第三方 AWS 帳戶 擁有的
當第三方需要存取您組織 AWS 的資源時，您可以使用 角色來委派存取權給他們。例如，第三方可能提供一種用於管理您的 AWS 資源之服務。透過 IAM 角色，您可以授予這些第三方存取 資源 AWS 的權限，而無需共用您的 AWS 安全登入資料。相反地，第三方可以透過擔任您在 中建立的角色來存取您的 AWS 資源 AWS 帳戶。若要了解在您信任區域 (受信任組織或帳戶) 外帳戶中的主體是否具有擔任您角色的許可，請參閱[什麼是 IAM Access Analyzer？](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)。
為了建立他們可以代入的角色，第三方必須為您提供以下資訊：
+ **第三方的 AWS 帳戶 ID**。為角色定義信任政策時，可將其 AWS 帳戶 ID 指定為主體。
+ **與角色唯一關聯的外部 ID**。外部 ID 可以是只有您和第三方知道的任何識別碼。例如，您可以使用您與該第三方之間的發票 ID，但不要使用能被猜到的內容，例如第三方的電話號碼。為角色定義信任政策時，必須指定該 ID。第三方在代入角色時必須提供該 ID。
+ **第三方為使用您的 AWS 資源而請求獲得的許可**。定義角色的許可政策時，必須指定這些許可。這個政策定義了他們可以執行哪些操作以及可以存取哪些資源。
建立完角色後，您必須向第三方提供該角色的 Amazon Resource Name (ARN)。他們需要使用您的角色的 ARN 來代入該角色。
**重要**
當您授予第三方存取 資源的權限時 AWS ，他們可以存取您在政策中指定的任何資源。他們使用的資源費用將由您支付。請確保適當地限制他們對資源的使用。
## 第三方存取的外部 ID
外部 ID 允許正擔任該角色的使用者聲明所操作的環境。它還為帳戶擁有者提供一種方法來允許僅在特定情況下擔任該角色。外部 ID 的主要功能是解決並防止 [混淆代理人問題](confused-deputy.md)。
**重要**
AWS 不會將外部 ID 視為秘密。在您建立存取金鑰對或密碼等秘密之後 AWS，就無法再次檢視它們。具有檢視角色許可的任何人都可看見角色的外部 ID。
## 我何時應使用外部 ID？
在以下情況下使用外部 ID：
+ 您是 AWS 帳戶 擁有者，而且已為存取 AWS 帳戶 您 以外的其他 的第三方設定角色。您應要求第三方提供其在擔任您的角色時包含的外部 ID。然後，在您角色的信任政策中檢查該外部 ID。這樣做可確保外部方僅在代表您執行操作時才能擔任您的角色。
+ 在前述情況下，您代表不同客戶 (如 Example Corp) 擔任角色。您應該為每個客戶分配一個唯一的外部 ID 並指導他們將該外部 ID 加入到其角色的信任政策。然後，您必須確保在代入角色的請求中始終包含正確的外部 ID。
您可能已為您的每個客戶提供一個獨有識別碼，而且此獨有 ID 足以用作外部 ID。該外部 ID 不是您要明確建立或分別追蹤所需的特殊值 (僅用於此目的)。
您應始終在您的 `AssumeRole` API 呼叫中指定外部 ID。此外，在客戶為您提供角色 ARN 時，請測試是否能在含有/不含有正確外部 ID 的情況下擔任該角色。如果可在沒有正確外部 ID 的情況下擔任角色，則請勿在您的系統中儲存該客戶的角色 ARN。等待該客戶將角色信任政策更新為要求提供正確的外部 ID。這樣一來，您協助您的客戶執行了正確的操作，並幫助您和客戶避免了混淆代理人問題。
## 使用外部 ID 的範例案例
例如，假設您決定聘請名為 Example Corp 的第三方公司來監控您的 AWS 帳戶 並協助最佳化成本。為了追蹤您的每日花費，Example Corp 需要存取您的 AWS 資源。Example Corp 也可監控其他客戶的許多其他 AWS 帳戶。
請不要向 Example Corp 提供對您 AWS 帳戶中的 IAM 使用者和其長期憑證的存取權。請改用 IAM 角色及其臨時安全性憑證。IAM 角色提供一種機制，允許第三方存取您的 AWS 資源，而不需要共用長期憑證 （例如 IAM 使用者存取金鑰）。
您可以使用 IAM 角色，在您的 AWS 帳戶 與 Example Corp 帳戶之間建立信任關係。建立此關係後，Example Corp 帳戶的成員可以呼叫 AWS Security Token Service [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 來取得臨時安全登入資料。Example Corp 成員接著可以使用登入資料來存取您帳戶中 AWS 的資源。
**注意**
如需 AssumeRole 和其他您可以呼叫以取得臨時安全登入資料之 AWS API 操作的詳細資訊，請參閱 [比較 AWS STS 登入資料](id_credentials_sts-comparison.md)。
以下是此方案的更多詳細資訊：
1. 您聘請了 Example Corp，此公司將為您建立獨有的客戶識別碼。他們為您提供這個唯一的客戶 ID 及其 AWS 帳戶 號碼。您需要此資訊來在下一個步驟中建立 IAM 角色。
**注意**
Example Corp 可使用其想用於 ExternalId 的任何字串值，只要該值對於每個客戶來說都是獨有的。該值可以是客戶帳戶，甚至可以是一個隨機字串，只要沒有兩個客戶擁有相同的值即可。該值不是「機密」。Example Corp 必須為每個客戶提供 ExternalId 值。關鍵在於，該值必須由 Example Corp 而***非***由其客戶產生，以確保每個外部 ID 都是唯一的。
1. 您登入 AWS 並建立 IAM 角色，讓 Example Corp 存取您的 資源。與任何 IAM 角色類似，該角色具有兩個政策：許可政策和信任政策。角色的信任政策指定擔任該角色的對象。在我們的範例案例中，政策會將 Example Corp AWS 帳戶 的數量指定為 `Principal`。這允許來自此帳戶的身分擔任該角色。此外，您新增 `[Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition)` 元素到信任政策。此 `Condition` 測試 `ExternalId` 內容索引鍵，以確保它與 Example Corp 的獨有客戶 ID 一致。例如：
```
"Principal": {"AWS": "Example Corp's AWS 帳戶 ID"},
"Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
```
1. 該角色的許可政策指定該角色允許某個人執行哪些操作。例如，您可以指定該角色允許某人只能管理您的 Amazon EC2 和 Amazon RDS 資源，但不能管理您的 IAM 使用者或群組。在我們的範例方案中，您使用許可政策為 Example Corp 授予帳戶中的所有資源的唯讀存取許可。
1. 建立完角色後，為 Example Corp 提供該角色的 Amazon Resource Name (ARN) (ARN)。
1. 當 Example Corp 需要存取您的 AWS 資源時，公司的某人會 AWS `sts:AssumeRole`呼叫 API。此呼叫包括要擔任的角色的 ARN 和與其客戶 ID 對應的 ExternalId 參數。
如果請求來自使用 Example Corp 的某人 AWS 帳戶，且角色 ARN 和外部 ID 正確，則請求會成功。然後，它會提供臨時安全登入資料，讓 Example Corp 可用來存取您的角色允許 AWS 的資源。
換言之，當角色政策包括外部 ID 時，任何需要擔任該角色的人都必須是該角色中的主體，還必須包括正確的外部 ID。
## 外部 ID 的要點
+ 在多租戶環境中，您支援具有不同 AWS 帳戶的多個客戶，我們建議每個客戶使用一個外部 ID AWS 帳戶。此 ID 應該是由第三方產生的隨機字串。
+ 如要請求第三方在取得角色時提供外部 ID，請使用您選擇的外部 ID 來更新角色的信任政策。
+ 若要在擔任角色時提供外部 ID，請使用 AWS CLI 或 AWS API 擔任該角色。如需詳細資訊，請參閱 STS [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 操作，或是 STS [assume-role](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html) CLI 操作。
+ `ExternalId` 值必須最少為 2 個字元，最多為 1,224 個字元。該值必須為英數字元，且不包含空格。也可以包含下列符號：加號 (\$1)、等號 (=)、逗號 (,)、句號 (.)、小老鼠 (@)、冒號 (:)、正斜線 (/) 和連字號 (-)。
## 其他資源
下列資源可協助您進一步了解如何提供對第三方擁有的 AWS 帳戶 的存取權。
+ 若要了解如何允許其他人在您的 中執行動作 AWS 帳戶，請參閱 [使用自訂信任政策建立角色](id_roles_create_for-custom.md)。
+ 若要了解如何授予許可以切換至角色，請參閱[向使用者授予切換角色的許可](id_roles_use_permissions-to-switch.md)
+ 若要了解如何建立並向信任的使用者提供臨時安全憑證，請參閱[臨時安全憑證的許可](id_credentials_temp_control-access.md)。
# 存取 AWS 服務
許多 AWS 服務要求您使用 角色來控制該服務可存取的內容。服務會擔任代您執行動作的角色稱為[服務角色](id_roles.md#iam-term-service-role)。當角色做為服務的專業用途時，它可以歸類為[服務連結角色](id_roles.md#iam-term-service-linked-role)。請參閱每個服務的 [AWS 文件](https://docs.aws.amazon.com/)，以查看它是否使用角色，以及了解如何指派角色以供服務使用。
如需建立角色以委派存取 提供的服務的詳細資訊 AWS，請參閱 [建立角色以將許可委派給 AWS 服務](id_roles_create_for-service.md)。
# 對外部驗證的使用者的存取權 (聯合身分)
您的使用者可能已經在 外部擁有身分 AWS，例如在您的公司目錄中。如果這些使用者需要使用 AWS 資源 （或使用存取這些資源的應用程式），則這些使用者也需要 AWS 安全登入資料。您可以使用 IAM 角色為從您的組織或第三方身分提供者 (IdP) 聯合身分的使用者指定許可。
**注意**
作為安全最佳實務，建議您使用聯合身分在 [IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/what-is.html) 中管理使用者存取權，而不是建立 IAM 使用者。若要了解需要 IAM 使用者的特定情形，請參閱[建立 IAM 使用者 (而非角色) 的時機](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose)。
## 使用 Amazon Cognito 聯合行動或以 Web 為基礎的應用程式的使用者
如果您建立可存取 AWS 資源的行動或 Web 應用程式，則應用程式需要安全登入資料，才能向 發出程式設計請求 AWS。對於大多數行動應用程式藍本，建議您使用 [Amazon Cognito](https://aws.amazon.com/cognito/)。您可以將此服務與適用於 [AWS iOS 的 Mobile SDK](https://aws.amazon.com/sdkforios/) 和[AWS 適用於 Android 和 Fire OS 的 Mobile SDK](https://aws.amazon.com/sdkforandroid/) 搭配使用，為使用者建立唯一身分，並對其進行驗證，以安全地存取您的 AWS 資源。Amazon Cognito 支援與下一個部分中列出的身分提供者相同的身分提供者，並且還支援[開發人員驗證身分](https://aws.amazon.com/blogs/mobile/amazon-cognito-announcing-developer-authenticated-identities)和未經身分驗證 (訪客) 的存取。Amazon Cognito 還提供 API 操作以同步使用者資料，如此可在使用者於不同裝置之間移動時進行保留。如需詳細資訊，請參閱 [用於行動應用程式的 Amazon Cognito](id_federation_common_scenarios.md#id_roles_providers_oidc_cognito)。
## 使用公有身分服務提供者或 OpenID Connect 來聯合使用者
在可能的情況下，將 Amazon Cognito 用於行動和以 Web 為基礎的應用程式案例。Amazon Cognito 為您提供公有身分提供者服務的大部分幕後工作。它適用於相同的第三方服務，並且還支援匿名登入。但是，對於更進階的案例，您可以直接使用 Login with Amazon、Facebook、Google 或與 OpenID Connect (OIDC) 相容的任何 IdP 等第三方服務。如需有關使用 OIDC 聯合身分來使用其中一項服務的詳細資訊，請參閱 [OIDC 聯合身分](id_roles_providers_oidc.md)。
## 使用 SAML 2.0 聯合使用者
如果您的組織已使用支援 SAML 2.0 （安全性聲明標記語言 2.0) 的身分提供者軟體套件，您可以在組織之間建立信任做為身分提供者 (IdP) 和 AWS 做為服務提供者。然後，您可以使用 SAML 為使用者提供 AWS 管理主控台 或 聯合身分的單一登入 (SSO)，以呼叫 AWS API 操作。例如，如果您的公司使用 Microsoft Active Directory 和 Active Directory Federation Services，則可以使用 SAML 2.0 聯合。如需有關使用 SAML 2.0 聯合使用者的詳細資訊，請參閱[SAML 2.0 聯合身分](id_roles_providers_saml.md)。
## 透過建立自訂身分經紀人應用程式來聯合使用者
如果您的身分存放區與 SAML 2.0 不相容，則可以建置自訂身分經紀人應用程式以執行類似的功能。代理程式應用程式會驗證使用者、請求使用者的臨時登入資料 AWS，然後將他們提供給使用者以存取 AWS 資源。
例如，Example Corp. 有許多員工需要執行存取公司 AWS 資源的內部應用程式。員工已經在公司身分和身分驗證系統中擁有身分，而 Example Corp. 不想要為每個公司員工建立個別的 IAM 使用者。
Bob 是 Example Corp. 的開發人員。 為了讓 Example Corp. 內部應用程式能夠存取公司的 AWS 資源，Bob 開發了自訂身分代理程式應用程式。該應用程式驗證員工是否已登入到現有的 Example Corp. 身分和身分驗證系統，該系統可能使用 LDAP、Active Directory 或其他系統。然後，身分經紀人應用程式取得員工的臨時安全憑證。此案例類似於前一個案例 （使用自訂身分驗證系統的行動應用程式），但需要存取 AWS 資源的應用程式全都在公司網路中執行，而且公司有現有的身分驗證系統。
若要取得臨時安全憑證，身分經紀人應用程式將呼叫 `AssumeRole` 或 `GetFederationToken` 以取得臨時安全憑證，具體取決於 Bob 想要如何管理使用者政策以及臨時憑證何時過期。(如需有關這些 API 操作間差異的詳細資訊，請參閱 [IAM 中的暫時安全憑證](id_credentials_temp.md) 和 [臨時安全憑證的許可](id_credentials_temp_control-access.md))。呼叫會傳回暫時性安全登入資料，其中包含 AWS 存取金鑰 ID、私密存取金鑰和工作階段字符。身分經紀人應用程式讓這些臨時安全憑證可供內部公司應用程式使用。然後，應用程式可以使用臨時憑證直接呼叫 AWS 。該應用程式快取憑證，直到過期，然後請求一組新的臨時憑證。下圖說明此情況。
![\[使用自訂身分經紀人應用程式的範例工作流程\]](http://docs.aws.amazon.com/zh_tw/IAM/latest/UserGuide/images/enterprise-authentication-with-identity-broker-application.diagram.png)
此案例具有以下屬性：
+ 身分經紀人應用程式有權存取 IAM 的權杖服務 (STS) API 來建立臨時安全憑證。
+ 身分經紀人應用程式能夠驗證員工是否在現有身分驗證系統中進行了身分驗證。
+ 使用者可以取得臨時 URL，讓他們能夠存取 AWS 管理主控台 （稱為單一登入）。
如需建立臨時安全性憑證檔案的詳細資訊，請參閱 [比較 AWS STS 登入資料](id_credentials_sts-comparison.md)。如需 SAML 聯合身分主體存取 AWS 管理主控台的詳細資訊，請參閱 [啟用 SAML 2.0 聯合主體來存取 AWS 管理主控台](id_roles_providers_enable-console-saml.md)。