GetFederationToken のアクセス権限

GetFederationToken オペレーションは、IAM ユーザーによって呼び出され、そのユーザーの一時的な認証情報を返します。このオペレーションでは、ユーザーをフェデレーションします。フェデレーティッドユーザーが割り当てられたアクセス権限は、次の 2 か所のどちらかで定義されます。

• GetFederationToken API コールのパラメータとして渡されるセッションポリシー。（こちらが普通です)。

• ポリシーの Principal 要素でフェデレーティッドユーザーを明示的に指名するリソースベースのポリシー (こちらはそれほど一般的ではありません)。

セッションポリシーは、一時セッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。フェデレーティッドユーザーセッションを作成し、セッションポリシーを渡すと、結果として得られるセッションのアクセス許可は、 ユーザーのアイデンティティベースのポリシーとセッションポリシーの共通部分です。セッションポリシーを使用して、フェデレーションされているユーザーのアイデンティティベースのポリシーによって許可されている以上のアクセス許可を付与することはできません。

ほとんどの場合、GetFederationToken API 呼び出しでポリシーを渡さなければ、返される一時的なセキュリティ認証情報はアクセス権限を持ちません。ただし、リソースベースのポリシーでは、セッションに追加のアクセス許可を提供できます。セッションを許可されたプリンシパルとして指定するリソースベースのポリシーを使用してリソースにアクセスできます。

次の図は、ポリシーがどのように相互作用して、GetFederationToken の呼び出しによって返される一時的なセキュリティ認証情報のアクセス権限が決まるかを視覚的に示しています。

例: GetFederationToken を使用してアクセス権限を割り当てる

GetFederationToken API アクションをさまざまなポリシーと共に使用できます。ここにいくつか例を挙げます。

ポリシーを IAM ユーザーにアタッチするには

この例では、2 つのバックエンドウェブサービスに頼ったブラウザベースのクライアントアプリケーションがあります。1 つのバックエンドサービスは、独自の ID システムを使用してクライアントアプリケーションを認証する独自の認証サーバーです。もう 1 つのバックエンドサービスは、クライアントアプリケーションの機能の一部を提供する AWS サービスです。クライアントアプリケーションはサーバーによって認証され、サーバーは適切なアクセス許可ポリシーを作成または取得します。サーバーは、続いて、GetFederationToken API を呼び出して一時的なセキュリティ認証情報を取得し、その認証情報をクライアントアプリケーションに返します。クライアントアプリケーションは、その後、一時的なセキュリティ認証情報を使って AWS サービスに対してリクエストを直接行うことができます。このアーキテクチャでは、AWS 長期的認証情報を埋め込まなくても、クライアントアプリケーションが AWS リクエストを実行できます。

認証サーバーは、GetFederationToken という名前の IAM ユーザーの長期的なセキュリティ認証情報を使用して token-app API を呼び出します。ただし、長期的な IAM ユーザー認証情報はサーバーにとどまり、決してクライアントには配布されません。以下の例のポリシーは、token-app IAM ユーザーにアタッチされ、フェデレーションユーザー (クライアント) が必要とする最も広範なアクセス権限を定義します。フェデレーティッドユーザーの一時的なセキュリティ認証情報を取得するには、認証サービスに sts:GetFederationToken アクセス許可が必要となることに注意してください。

注記

AWS にはこの目的にかなったサンプル Java アプリケーションが用意されていて、「ID 登録のためのトークン自動販売機 - サンプル Java ウェブアプリケーション」からダウンロードできます。

例 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 呼び出しのパラメータとしてポリシーを渡さない場合、結果として、フェデレーションユーザーは有効なアクセス許可を持ちません。

パラメータとして渡されたセッションポリシー

フェデレーティッドユーザーに適切なアクセス許可を確実に割り当てる最も一般的な方法は、GetFederationToken API 呼び出しでセッションポリシーを渡すことです。前の例を拡張して、GetFederationToken が IAM ユーザー token-app の認証情報を使用して呼び出されると仮定します。次に、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 リソースはリソースベースのポリシーをサポートし、このポリシーはフェデレーティッドユーザーにアクセス許可を直接付与するもう 1 つの仕組みとして利用できます。一部の AWS サービスのみでリソースに基づくポリシーをサポートしています。たとえば、Amazon S3 にはバケット、Amazon SNS にはトピック、Amazon SQS にはキューがあり、これらにポリシーをアタッチできます。リソースベースのポリシーをサポートするすべてのサービスのリストについては、「IAM と連携する AWS のサービス」を参照の上、テーブルの「リソースベースのポリシー」列を確認してください。リソースベースのポリシーを使用して、フェデレーションユーザーに直接アクセス許可を割り当てることができます。そのためには、リソースベースのポリシーの Principal 要素でフェデレーティッドユーザーの Amazon Resource Name (ARN) を指定します。以下の例では、これを表し、また productionapp という名前の S3 バケットを使用して前の例を拡張しています。

次のリソースベースのポリシーは、バケットにアタッチされています。このバケットポリシーでは、Carol という名前のフェデレーティッドユーザーにバケットへのアクセスを許可します。前に示したサンプルポリシーが token-app IAM ユーザーにアタッチされていると、Carol というフェデレーティッドユーザーには、s3:GetObject、s3:PutObject、s3:DeleteObject アクションを productionapp という名前のバケットに対して実行するアクセス許可が付与されています。これは、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/*"]
  }
}

ポリシーの評価方法の詳細については、「ポリシーの評価論理」を参照してください。