GetFederationToken 的許可 - AWS Identity and Access Management

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

GetFederationToken 的許可

GetFederationToken作業會由IAM使用者呼叫,並傳回該使用者的暫時認證。此操作會聯合使用者。指派給聯合身分使用者的許可在以下其中兩個地方定義:

  • 會話策略作為調用的參數傳GetFederationTokenAPI遞。(這是最常見的)。

  • 資源為基礎的政策,而聯合身分使用者明確名稱在 Principal 元素政策。(這是最少見的)。

工作階段政策是一種進階政策,且您會在以程式設計方式建立臨時工作階段時,以參數方式傳遞此政策。建立聯合身分使用者工作階段並傳遞工作階段政策時,所產生工作階段的許可會是 使用者的身分類型政策和工作階段政策的交集。您無法使用工作階段政策來授予超出即將聯合使用者之以身分為基礎政策所允許的許可。

在大多數情況下,如果您未在GetFederationTokenAPI呼叫中傳遞策略,則產生的臨時安全登入資料沒有權限。不過,以資源為基礎的政策可提供該工作階段的額外許可。您可以使用以資源為基礎的政策存取資源,該政策會將您的工作階段指定為允許的主體。

下圖顯示政策互動的視覺化呈現,以判斷對 GetFederationToken 呼叫傳回的暫時安全憑證的許可。

IAM 使用者下圖顯示核取標記,表示工作階段權限是使用者以身分識別為基礎的原則與工作階段原則的交集。工作階段權限也可以是使用者以身分識別為基礎的原則和以資源為基礎的原則的交集。

範例:使用指派權限 GetFederationToken

您可以對不同類型的策略使用此GetFederationTokenAPI動作。以下是幾個範例。

附加至IAM使用者的策略

在這個範例中,您有一個以瀏覽器為基礎的用戶端應用程式,它依賴於兩個後端的 Web 服務。一個後端服務是您自己的身分驗證伺服器,使用您自己的身分系統來驗證用戶端應用程式。另一個後端服務是 AWS 服務,可提供一些用戶端應用程式的功能。用戶端應用程式由您的伺服器進行身分驗證,您的伺服器會建立或擷取適當的許可政策。然後,您的伺服器會呼叫GetFederationTokenAPI以取得臨時安全登入資料,並將這些認證傳回給用戶端應用程式。然後,用戶端應用程式可以使用臨時安全登入資料直接向 AWS 服務發出要求。此架構可讓用戶端應用程式在不內嵌長期 AWS 認證的情況下 AWS 提出要求。

您的驗證伺服器會使GetFederationTokenAPI用名為的IAM使用者的長期安全性登入資料呼叫token-app。但是長期IAM使用者認證會保留在您的伺服器上,而且永遠不會分發給用戶端。下列範例原則會附加至token-appIAM使用者,並定義您的同盟使用者 (用戶端) 所需的最廣泛的權限集。請注意,身分驗證服務需要 sts:GetFederationToken 許可才能取得聯合身分使用者的暫時安全憑證。

注意

AWS 提供了一個示例 Java 應用程序來實現此目的,您可以在此處下載:用於身份註冊的令牌自動售貨機-示例 Java Web 應用程序

範例 附加至呼叫token-app之IAM使用者的範例原則 GetFederationToken
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:GetFederationToken", "Resource": "*" }, { "Effect": "Allow", "Action": "dynamodb:ListTables", "Resource": "*" }, { "Effect": "Allow", "Action": "sqs:ReceiveMessage", "Resource": "*" }, { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "*" }, { "Effect": "Allow", "Action": "sns:ListSubscriptions", "Resource": "*" } ] }

上述策略會將數個權限授與使IAM用者。不過,單靠此政策不會將任何許可授予聯合身分使用者。如果此IAM使用者呼叫GetFederationToken且未將原則作為API呼叫的參數傳遞,則產生的同盟使用者沒有有效的權限。

工作階段政策作為參數傳遞

確保已為同盟使用者指派適當權限的最常用方法是在GetFederationTokenAPI呼叫中傳遞工作階段原則。擴展前面的例子,想像GetFederationToken一下,IAM使用用戶的憑據調用token-app。然後想像下面的會話策略作為API調用的參數傳遞。所產生的聯合身分使用者具有列出名為 productionapp 的 Amazon S3 儲存貯體內容的許可。該使用者無法對 productionapp 儲存貯體中的項目執行 Amazon S3 GetObjectPutObjectDeleteObject 動作。

這些權限會指派給同盟使用者,因為這些權限是IAM使用者原則與您傳遞的工作階段原則的交集。

聯合身分使用者無法在 Amazon SNS、Amazon、亞馬 Amazon DynamoDB 或任何 S3 儲存貯體中執行動作,除了。SQS productionapp即使這些權限已授與GetFederationToken呼叫相關聯的IAM使用者,仍會拒絕這些動作。

範例 作為調用參數傳遞的會GetFederationTokenAPI話策略示例
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": ["arn:aws:s3:::productionapp"] }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": ["arn:aws:s3:::productionapp/*"] } ] }

資源型政策

某些 AWS 資源支援以資源為基礎的政策,而且這些原則提供另一種機制,可直接將權限授與同盟使用者。只有部分 AWS 服務支援資源型政策。例如,Amazon S3 有存儲桶,Amazon SNS 有主題,Amazon SQS 有隊列,您可以將政策附加到。如需有關支援以資源為基礎的政策的所有服務的清單,請參閱 AWS 使用 的 服務 IAM 並查看表格中的「以資源為基礎的政策」資料列。您可以使用以資源為基礎的政策來將許可直接指派至聯合身分使用者。透過在以資源為基礎的政策的Principal元素中指定聯合身分使用者的 Amazon 資源名稱 (ARN) 來執行此操作。以下範例使用名為 productionapp 的 S3 儲存貯體說明此範例並擴展前面的範例。

以下以資源為基礎的政策已連接到儲存貯體。此儲存貯體政策可讓名為 Carol 的聯合身分使用者存取儲存貯體。將先前描述的範例原則附加至token-appIAM使用者時,名為 Carol 的聯合身分使用者擁有對名productionapp為的值區執行s3:GetObjects3:PutObject、和s3:DeleteObject動作的權限。即使沒有會話策略作為GetFederationTokenAPI調用的參數傳遞,也是如此。這是因為在這種情況下,名為 Carol 的聯合身分使用者已透過以下以資源為基礎的政策明確授予許可。

請記住,只有在明確授與使用者和同盟使用者的權限時,聯合身分IAM使用者才會被授權限。在以資源為基礎的政策中,運用 Principal 元素來明確命名聯合身分使用者,也可以授予這些許可 (在帳戶內),如下面範例所示。

範例 允許存取聯合身分使用者的儲存貯體政策範例
{ "Version": "2012-10-17", "Statement": { "Principal": {"AWS": "arn:aws:sts::account-id:federated-user/Carol"}, "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": ["arn:aws:s3:::productionapp/*"] } }

如需有關如何評估政策的詳細資訊,請參閱政策評估邏輯