GetFederationToken 許可

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

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

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

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

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

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

範例：使用 GetFederationToken 指派許可

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

連接至 IAM 使用者的政策

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

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

注意

AWS 提供範例 Java 應用程式來達成此目的，您可以在這裡下載：適用於身分註冊的權杖販賣機 - 範例 Java Web 應用程式。

範例 連接到呼叫 GetFederationToken 的 IAM 使用者 token-app 的政策範例

{
  "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 呼叫的參數傳遞，則產生的聯合身分使用者將不具有有效許可。

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

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

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

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

範例 工作階段政策作為 GetFederationToken API 呼叫的參數傳遞範例

{
  "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 Resource Name (ARN)。以下範例使用名為 productionapp 的 S3 儲存貯體說明此範例並擴展前面的範例。

以下以資源為基礎的政策已連接到儲存貯體。此儲存貯體政策可讓名為 Carol 的聯合身分使用者存取儲存貯體。當先前所述的範例政策連接到 token-app IAM 使用者時，名為 Carol 的聯合身分使用者便具有對名為 productionapp 的儲存貯體執行 s3:GetObject、s3:PutObject 和 s3:DeleteObject 動作的許可。即使沒有工作階段政策做為 GetFederationToken API 呼叫的參數傳遞時，也是如此。這是因為在這種情況下，名為 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/*"]
  }
}

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