常用案例 - AWS Identity and Access Management

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

常用案例

注意

我們建議您要求您的人類使用者在存取時使用臨時登入資料 AWS。你有沒有考慮過使用 AWS IAM Identity Center? 您可以使用 IAM Identity Center 集中管理多個存取權限, AWS 帳戶 並從一個位置為使用者提供MFA受保護的單一登入存取所有指派帳戶。透過IAM身分識別中心,您可以在IAM身分識別中心建立和管理使用者身分,或輕鬆連線至現有的 SAML 2.0 相容身分識別提供者。如需詳細資訊,請參閱什麼是IAM身分識別中心?《AWS IAM Identity Center 使用者指南》中。

您可以使用外部身分識別提供者 (IdP) 來管理. 以及外部 IdP 以外的使用者身分識別 AWS。外部 IdP 可以為 AWS 使用 OpenID Connect(OIDC)或安全斷言標記語言(SAML)提供身份信息。OIDC當不執行的應用程式 AWS 需要存取 AWS 資源時,通常會使用。

當您想要設定與外部 IdP 的聯合時,您可以建立IAM身分識別提供者來通 AWS 知外部 IdP 及其組態。這會在您 AWS 帳戶 與外部 IdP 之間建立信任。下列主題提供使用IAM身分識別提供者的常見案例。

Amazon Cognito 動應用程式

使用OIDC聯合會的首選方式是使用 Amazon Cognito。例如,開發人員 Adele 正在為行動裝置建置遊戲,其中分數和描述檔這類使用者資料都存放在 Amazon S3 和 Amazon DynamoDB 中。Adele 也會將此資料存放在裝置本機,並使用 Amazon Cognito 跨多個裝置保持同步。她了解為了安全和維護之故,長期的 AWS 安全憑證不應隨遊戲發散。她也了解遊戲可能有大量的使用者。基於上述所有原因,她不想在中IAM為每個玩家建立新的使用者身分。相反,她構建了遊戲,以便用戶可以使用他們已經與知名的外部身份提供商(IdP)建立的身份登錄,例如使用亞馬遜Facebook谷歌或任何 OpenID Connect(OIDC)兼容的 IdP 登錄。她的遊戲可善用其中一個提供者的身分驗證機制,藉以驗證使用者的身分。

為了使移動應用程序能夠訪問她的 AWS 資源,阿黛爾首先使用她選擇 IdPs的開發人員 ID 註冊。她也會使用這些提供者的每一個來設定應用程式。在包 AWS 帳戶 含遊戲的 Amazon S3 儲存貯體和 DynamoDB 表格中,Adele 使用 Amazon Cognito 建立可精確定義遊戲所需許可的IAM角色。如果她使用 OIDC IdP,她還會建立一個IAMOIDC身分供應商實體,以在其中的 Amazon Cognito 身分集區 AWS 帳戶 與 IdP 之間建立信任。

在應用程式的程式碼中,Adele 呼叫用於之前設定的 IdP 的登入介面。IdP 處理讓用戶登錄的所有詳細信息,並且應用程序從提供程序獲OAuth取訪問令牌或 OIDC ID 令牌。Adele 的應用程序可以將此身份驗證信息交換為由訪問密鑰 ID,秘密 AWS 訪問密鑰和會話令牌組成的一組臨時安全憑據。然後,應用程序可以使用這些憑據訪問提供的 Web 服務 AWS。該應用程式僅限於許可,其定義於其擔任的角色。

下圖使用 Login with Amazon 做為 IdP,顯示一個有關如何運作的簡化流程。對於步驟 2,該應用程序還可以使用 Facebook,谷歌或任何OIDC兼容的 IdP,但這不顯示在這裡。

使用 Amazon Cognito 的範例工作流程來聯合行動應用程式的使用者

  1. 客戶在行動裝置啟動您的應用程式。該應用程式要求使用者登入。

  2. 該應用程式會使用 Login with Amazon 資源來接受使用者的憑證。

  3. 該應用程序使用 Amazon Cognito API 操作,GetIdGetCredentialsForIdentity將 Login with Amazon ID 令牌交換為 Amazon Cognito 令牌。Amazon Cognito 已設定為信任您的 Login with Amazon 專案,會產生一個權杖,它與 AWS STS交換暫存工作階段憑證。

  4. 該應用程序從 Amazon Cognito 接收暫時安全憑證。您的應用程式也可以使用 Amazon Cognito 中的基本 (傳統) 工作流程,從 AWS STS 使AssumeRoleWithWebIdentity用中擷取權杖。如需詳細資訊,請參閱《Amazon Cognito 開發人員指南》中的身分集區 (聯合身分) 驗證流程

  5. 透過應用程式可使用暫時性安全憑證存取操作應用程式所需的任何 AWS 資源。與暫時性安全憑證相關聯的角色及指派政策,決定了可以存取哪些內容。

使用下列程序將應用程式設定為使用 Amazon Cognito 驗證使用者,並將 AWS 資源存取權授予應用程式。如需關於完成此案例的特定步驟,請參閱 Amazon Cognito 的說明文件。

  1. (可選)註冊成為開發人員,使用亞馬遜,Facebook,谷歌或任何其他 OpenID Connect(OIDC)兼容的 IdP 登錄,並與提供商配置一個或多個應用程序。此步驟是可選的,因為 Amazon Cognito 也支援未經驗證的使用者存取權 (訪客)。

  2. Amazon Cognito 在 AWS Management Console. 使用 Amazon Cognito 精靈來建立身分集區,而該集區是一種容器,可讓 Amazon Cognito 用於為您的應用程式整理最終使用者身分。您可以在應用程式之間分享身分集區。設定身分集區時,Amazon Cognito 會建立一或兩個IAM角色 (一個用於驗證身分,另一個用於未驗證的「來賓」身分),以定義 Amazon Cognito 使用者的許可。

  3. 整合 AWSAmplify 與您的應用程式,並匯入所需檔案以使用 Amazon Cognito。

  4. 建立 Amazon Cognito 登入資料提供者的執行個體,傳遞身分集區 ID、您的 AWS 帳戶 號碼,以及與身分集區相關聯之角色的 Amazon 資源名稱 (ARN)。中的 Amazon Cognito 精靈 AWS Management Console 提供可協助您開始使用的範例程式碼。

  5. 當您的應用程序訪問 AWS 資源時,請將憑據提供程序實例傳遞給客戶端對象,該客戶端對象將臨時安全憑據傳遞給客戶端。憑證的許可是根據您稍早定義的一個或多個角色。

如需詳細資訊,請參閱下列內容:

OIDC行動應用程式的同盟

若要取得最佳結果,請在幾乎所有OIDC聯合案例中使用 Amazon Cognito 做為身分代理程式。Amazon Cognito 易於使用,並提供額外功能,如匿名 (未經身分驗證) 存取,以及跨裝置和提供者的同步使用者資料。不過,如果您已經透過手動呼叫建立使用OIDC同盟的應用程式 AssumeRoleWithWebIdentityAPI,您可以繼續使用該應用程式,而且您的應用程式仍可正常運作。

沒有 Amazon Cognito 的情況下使用OIDC聯合會的程序遵循以下一般概述:

  1. 使用 IdP 註冊為開發人員,並使用外部身分提供者 (IdP) 設定您的應用程式,IdP 為您的應用程式提供唯一 ID。(不同的 IdPs 使用不同的術語這個過程。 此大綱使用術語配置,用於使用 IdP 識別您的應用程序的過程。) 每個 IdP 都會為您提供該 IdP 唯一的應用程序 ID,因此,如果您將同一個應用程序配置為多個 IdPs,則您的應用程序將具有多個應用程序。IDs可依照每個提供商的要求配置多個應用程式。

    下列外部連結提供有關使用某些常用身分識別提供者 (IdPs) 的資訊:

    重要

    如果您使用來自谷歌,Facebook 或 Amazon Cognito 的OIDC身份提供商,請不要在中創建單獨的IAM身份提供商。 AWS Management Console AWS 內建這些OIDC身分識別提供者,可供您使用。略過下列步驟,並直接移至使用您的身分提供者建立新角色。

  2. 如果您使用的是谷歌,Facebook 或 Amazon Cognito 以外的 IdP 兼容OIDC,然後為其創建一個IAM身份提供者實體。

  3. 在中IAM,建立一或多個角色。對於每個角色,定義可以擔任角色的人員 (信任政策) 以及應用程式使用者擁有的許可 (許可政策)。一般而言,您可以為應用程式所支援的每個 IdP 建立一個角色。例如,您可以建立使用者透過 Login with Amazon 登入之應用程式可擔任的角色,使用者透過 Facebook 登入之相同應用程式可擔任的次要角色,以及使用者透過 Google 登入之應用程式可擔任的第三個角色。對於信任關係,請將 IdP (像是 Amazon.com) 指定為Principal (信任實體) 和包含符合 IdP 指派的應用程式 ID 的 Condition建立第三方身分識別提供者 (同盟) 的角色 中會說明不同提供者的角色範例。

  4. 在您的應用程式中,使用 IdP 對您的使用者進行身分驗證。有關如何執行此動作的具體情況會根據您所使用的 IdP (Login with Amazon、Facebook 或 Google) 以及您的應用程式執行的平台而有所不同。例如,Android 應用程序的身份驗證方法可能與 iOS 應用程序或 JavaScript基於 Web 應用程序的方法不同。

    一般而言,如果使用者尚未登入,則 IdP 會負責顯示登入頁面。在 IdP 驗證使用者之後,IdP 會向您的應用程式傳回帶有使用者資訊的身分驗證權杖。所包含的資訊取決於 IdP 公開的內容和使用者願意共用的資訊。您可以在您的應用程式中使用此資訊。

  5. 在您的應用程式中,對 AssumeRoleWithWebIdentity 動作進行未簽署呼叫以請求臨時安全性憑證。在請求中,您會傳遞 IdP 的身份驗證令牌,並為您為該 IdP 建立的IAM角色指定 Amazon 資源名稱 (ARN)。 AWS 驗證令牌是否受信任且有效,如果是,則將臨時安全憑據返回給您的應用程序,該憑據具有您在請求中命名的角色的權限。回應還包含來自 IdP 的有關使用者的中繼資料,例如 IdP 與使用者關聯的唯一使用者 ID。

  6. 使用響應中的臨時安全憑據,您的AssumeRoleWithWebIdentity應用程序向 AWS API操作發出簽名請求。來自 IdP 的用戶 ID 信息可以區分應用程序中的用戶。例如,您可以將物件放入包含使用者 ID 做為首碼或尾碼的 Amazon S3 資料夾。這可讓您建立鎖定該資料夾的存取控制政策,以便只有具有該 ID 的使用者才能存取它。如需詳細資訊,請參閱AWS STS 同盟使用者工作階段主體

  7. 您的應用程式必須快取臨時安全憑證,如此每次應用程式需要向 AWS發出請求時都不必取得新的憑證。在預設情況下,憑證可以使用一小時。當憑證過期 (或在此之前),您再次呼叫 AssumeRoleWithWebIdentity 以取得一組新的臨時安全憑證。根據 IdP 以及如何管理權杖,您可能需要在對 AssumeRoleWithWebIdentity 進行新呼叫之前重新整理 IdP 的權杖,因為 IdP 的權杖通常也會在固定時間後過期。如果您使 AWS SDK用 iOS 版或 Android 版,則可以使用「 AWS SDKA mazonSTSCredentials 提供者」動作,該動作可管理IAM臨時登入資料,包括視需要重新整理它們。