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

# 對外部驗證的使用者的存取權 (聯合身分)
<a name="id_roles_common-scenarios_federated-users"></a>

您的使用者可能已經在 外部擁有身分 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 為基礎的應用程式的使用者
<a name="id_roles_common-scenarios_federated-users-cognito"></a>

如果您建立可存取 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 來聯合使用者
<a name="id_roles_common-scenarios_federated-users-openId"></a>

在可能的情況下，將 Amazon Cognito 用於行動和以 Web 為基礎的應用程式案例。Amazon Cognito 為您提供公有身分提供者服務的大部分幕後工作。它適用於相同的第三方服務，並且還支援匿名登入。但是，對於更進階的案例，您可以直接使用 Login with Amazon、Facebook、Google 或與 OpenID Connect (OIDC) 相容的任何 IdP 等第三方服務。如需有關使用 OIDC 聯合身分來使用其中一項服務的詳細資訊，請參閱 [OIDC 聯合身分](id_roles_providers_oidc.md)。

## 使用 SAML 2.0 聯合使用者
<a name="id_roles_common-scenarios_federated-users-saml20"></a>

如果您的組織已使用支援 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)。

## 透過建立自訂身分經紀人應用程式來聯合使用者
<a name="id_roles_common-scenarios_federated-users-idbroker"></a>

如果您的身分存放區與 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)。