View a markdown version of this page

GetFederationToken 許可 - AWS Identity and Access Management

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

GetFederationToken 許可

此 GetFederationToken 操作是由 IAM 使用者所呼叫並會傳回該使用者的臨時憑證。此操作會聯合使用者。指派給 AWS STS 聯合身分使用者工作階段的許可定義在兩個位置之一:

  • 該工作階段政策會以 GetFederationToken API 呼叫的參數傳遞。(這是最常見的)。

  • 以資源為基礎的政策,在政策的 Principal元素中明確命名 AWS STS 聯合身分使用者工作階段。(這是最少見的)。

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

在大部分情況下,如果您未通過 GetFederationToken API 呼叫的政策,則所產生的暫時安全憑證沒有許可。不過,以資源為基礎的政策可提供該工作階段的額外許可。您可以使用以資源為基礎的政策存取資源,該政策會將您的工作階段指定為允許的主體。

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

IAM 使用者下圖顯示核取記號,指出工作階段許可是使用者身分型政策和工作階段政策的交集。工作階段許可也可以是使用者身分型政策和資源型政策的交集。

範例:使用 GetFederationToken 指派許可

您可以將 GetFederationToken API 動作與不同類型的政策一起使用。以下是幾個範例。

連接至 IAM 使用者的政策

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

您的身分驗證伺服器使用名為 token-app 之 IAM 使用者的長期安全憑證來呼叫 GetFederationToken API。但長期 IAM 使用者憑證會保持在伺服器上且絕對不會發佈到用戶端。下列範例政策會連接至 token-app IAM 使用者,並定義聯合身分使用者 AWS STS (用戶端) 所需的最廣泛許可集。請注意,您的身分驗證服務需要 sts:GetFederationToken許可,才能取得 AWS STS 聯合身分使用者的臨時安全登入資料。

範例連接到呼叫 GetFederationToken 的 IAM 使用者 token-app 的政策範例
JSON
{ "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 使用者。不過,此政策本身不會將任何許可授予 AWS STS 聯合身分使用者。如果此 IAM 使用者呼叫 GetFederationToken,且 未將政策作為 API AWS STS 呼叫的參數傳遞,則產生的聯合身分使用者沒有有效的許可。

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

確保 AWS STS 聯合身分使用者獲指派適當許可的最常見方法是在 GetFederationToken API 呼叫中傳遞工作階段政策。擴展前面的範例,假設使用 IAM 使用者 token-app 憑證來呼叫 GetFederationToken。假設以下工作階段政策做為 API 呼叫的參數傳遞。所產生的 AWS STS 聯合身分使用者具有列出名為 productionapp 的 Amazon S3 儲存貯體內容的許可。該使用者無法對 productionapp 儲存貯體中的項目執行 Amazon S3 GetObject、PutObject 和 DeleteObject 動作。

聯合身分使用者會獲派這些許可,因為這些許可是 IAM 使用者政策和您傳遞之工作階段政策的交集。

AWS STS 聯合身分使用者無法在 Amazon SNS、Amazon SQS、Amazon DynamoDB 或任何 S3 儲存貯體中執行動作,但 除外productionapp。即使這些許可已授予給與 GetFederationToken 呼叫相關聯的 IAM 使用者,這些動作仍然會遭到拒絕。

範例工作階段政策作為 GetFederationToken API 呼叫的參數傳遞範例
JSON
{ "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 STS 聯合身分使用者。只有部分 AWS 服務支援以資源為基礎的政策。例如,Amazon S3 具有儲存貯體,Amazon SNS 具有主題,並且 Amazon SQS 具有可以連接政策的佇列。如需有關支援以資源為基礎的政策的所有服務的清單,請參閱 AWS 使用 IAM 的 服務 並查看表格中的「以資源為基礎的政策」資料列。您可以使用資源型政策,直接將許可指派給 AWS STS 聯合身分使用者。透過在資源型政策的 Principal元素中指定 AWS STS 聯合身分使用者的 Amazon Resource Name (ARN) 來執行此操作。以下範例使用名為 productionapp 的 S3 儲存貯體說明此範例並擴展前面的範例。

以下以資源為基礎的政策已連接到儲存貯體。此儲存貯體政策允許名為 Carol AWS STS 的聯合身分使用者存取儲存貯體。當前述的範例政策連接至 token-app IAM 使用者時,名為 Carol AWS STS 的聯合身分使用者具有許可,可在名為 的儲存貯體上執行 s3:GetObject、 s3:PutObject和 s3:DeleteObject動作productionapp。即使沒有工作階段政策做為 GetFederationToken API 呼叫的參數傳遞時,也是如此。這是因為在此案例中,名為 Carol AWS STS 的聯合身分使用者已由下列以資源為基礎的政策明確授予許可。

請記住,只有當 AWS STS 這些許可明確授予 IAM 使用者和聯合身分使用者時, AWS STS 才會授予聯合身分使用者許可。也可以由以資源為基礎的政策授予 (在帳戶中),該政策在政策的 Principal元素中明確命名 AWS STS 聯合身分使用者,如下列範例所示。

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

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