# ウェブ ID フェデレーションの使用
多数のユーザーを対象とするアプリケーションを記述している場合、必要に応じて、*ウェブ ID フェデレーション*を使用して、認証と認可を実行できます。ウェブ ID フェデレーションは、個々の ユーザーを作成する必要性を排除します。代わりに、ユーザーは ID プロバイダーにサインインした後、一時的なセキュリティ資格情報を AWS Security Token Service (AWS STS) から取得できます。アプリケーションでは、この認証情報を使用して AWS サービスにアクセスできます。
ウェブアイデンティティフェデレーションでは、次のアイデンティティプロバイダーをサポートしています。
+ Login with Amazon
+ Facebook
+ Google
## ウェブアイデンティティフェデレーションに関するその他のリソース
ウェブアイデンティティフェデレーションの詳細を理解するのに、次のリソースが役に立ちます。
+ AWS デベロッパーブログの「[Web Identity Federation using the AWS SDK for .NET](https://aws.amazon.com/blogs/developer/web-identity-federation-using-the-aws-sdk-for-net) 」の記事では、ウェブ ID フェデレーションを Facebookで使用する方法について説明しています。記事には、ウェブ ID を持つ ロールを想定する方法や、一時的なセキュリティ認証情報を使用して AWS リソースにアクセスする方法を示す C\$1 のコードスニペットが含まれています。
+ [AWS Mobile SDK for iOS](https://aws.amazon.com/sdkforios/) と [AWS Mobile SDK for Android](https://aws.amazon.com/sdkforandroid/) には、サンプルアプリが含まれています。このアプリケーションには、アイデンティティプロバイダーを呼び出す方法、そのプロバイダーからの情報を使用して、一時的なセキュリティ認証情報を取得および使用する方法を示すコードが含まれています。
+ 記事「[Web Identity Federation with Mobile Applications](https://aws.amazon.com/articles/4617974389850313)」では、ウェブ ID フェデレーションについて説明し、ウェブ ID フェデレーションを使用して AWS リソースにアクセスする使用方法の例を挙げています。
## ウェブ ID フェデレーションのポリシー例
DynamoDB でウェブ ID フェデレーションを使用する方法を示すには、[詳細に設定されたアクセスコントロールのための IAM ポリシー条件の使用](specifying-conditions.md) で導入された *GameScores* テーブルに再度アクセスしてください。次に、*GameScores* のプライマリキーを示します。
****
| テーブル名 | プライマリキーのタイプ | パーティションキーの名前と型 | ソートキーの名前と型 |
| --- | --- | --- | --- |
| GameScores (UserId、GameTitle、...) | 複合 | 属性名: UserId 型: 文字列 | 属性名: GameTitle 型: 文字列 |
ここで、あるモバイルゲームアプリケーションがこのテーブルを使用し、そのアプリケーションでは、数千人、数百万人のユーザーをサポートする必要があるとします。この規模では、個別のアプリケーションユーザーを管理し、各ユーザーが *GameScores* テーブルの自分のデータにだけアクセスできることを確実にするのは非常に難しいです。多くのユーザーは、Facebook、Google、Login with Amazon などのサードパーティーの ID プロバイダーのアカウントを既に持っています。そのため、このようなプロバイダーのいずれかを利用して、認証タスクを行うことができます。
ウェブ ID フェデレーションを使用して認証を行うには、アプリケーションデベロッパーは、そのアプリケーションをアイデンティティプロバイダー（Login with Amazon など）に登録して、一意のアプリケーション ID を取得する必要があります。次に、デベロッパーはロールを作成する必要があります (この例では、このロールには *GameRole* という名前が付いています)。このロールには、IAM ポリシードキュメントを添付する必要があります。このドキュメントでは、アプリケーションが *GameScores* テーブルにアクセスできるように条件を指定します。
ユーザーは、ゲームをプレイするとき、ゲームアプリケーション内から Login with Amazon アカウントにサインインします。その後アプリケーションが AWS Security Token Service (AWS STS) を呼び出します。その際には Login with Amazon アプリ ID を指定し、*GameRole* でメンバーシップをリクエストします。AWS STS は一時的な AWS 認証情報をアプリケーションに返し、*GameRole* ポリシードキュメントに基づいて *GameScores* テーブルへのアクセスを許可します。
次の図は、これらの要素を組み合わせるとどのようになるかを示しています。
![\[ゲームアプリケーションのワークフロー。アプリは Amazon ID と AWS STS を使用して、DynamoDB テーブルにアクセスするための一時的な認証情報を取得します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/wif-overview.png)
**ウェブ ID フェデレーションの概要**
1. アプリケーションは、サードパーティのアイデンティティプロバイダーを呼び出して、ユーザーとアプリケーションを認証します。アイデンティティプロバイダーは、ウェブアイデンティティトークンをアプリケーションに返します。
1. アプリは AWS STS を呼び出し、ウェブアイデンティティトークンを入力として渡します。AWS STS は、アプリケーションを認可し、一時的な AWS アクセス認証情報をアプリケーションに渡します。アプリケーションは、IAM ロール (*GameRole*) を想定し、そのロールのセキュリティポリシーに従って AWS リソースにアクセスすることが許可されます。
1. アプリケーションは、DynamoDB をコールして、*GameScores* テーブルにアクセスします。アプリケーションは *GameRole* を想定しているので、そのロールに関連付けられたセキュリティポリシーの影響を受けます。ポリシードキュメントによって、ユーザーに属していないデータにアプリケーションはアクセスできません。
繰り返しになりますが、[詳細に設定されたアクセスコントロールのための IAM ポリシー条件の使用](specifying-conditions.md) に示されている *GameRole* のセキュリティポリシーは次のとおりです。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowAccessToOnlyItemsMatchingUserID",
"Effect":"Allow",
"Action":[
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:BatchWriteItem"
],
"Resource":[
"arn:aws:dynamodb:us-west-2:123456789012:table/GameScores"
],
"Condition":{
"ForAllValues:StringEquals":{
"dynamodb:LeadingKeys":[
"${www.amazon.com:user_id}"
],
"dynamodb:Attributes":[
"UserId",
"GameTitle",
"Wins",
"Losses",
"TopScore",
"TopScoreDateTime"
]
},
"StringEqualsIfExists":{
"dynamodb:Select":"SPECIFIC_ATTRIBUTES"
}
}
}
]
}
```
------
`Condition` 節によって、アプリケーションに表示される *GameScores* の項目が決まります。Login with Amazon ID と `UserId` の `GameScores` パーティションキーの値を比較することで、これを行います。このポリシーに列挙されている DynamoDB アクションのいずれかを使用して処理できるのは、現在のユーザーに属する項目だけです。テーブルのその他の項目にはアクセスできません。さらに、ポリシーに列挙されている特定の属性にだけアクセスできます。
# ウェブ ID フェデレーションを使用するための準備
アプリケーションデベロッパーがアプリケーションにウェブ ID フェデレーションを使用する場合、次のステップに従います。
1. **デベロッパーとしてサードパーティーの ID プロバイダーにサインアップします。**次の外部リンクには、サポートされる ID プロバイダーへのサインアップに関する情報が記載されています。
+ [Login with Amazon デベロッパーセンター](http://login.amazon.com/)
+ Facebook サイトの[登録](https://business.facebook.com/business/loginpage)
+ Google サイトの [OAuth 2.0 を使用して Google API にアクセスする](https://developers.google.com/accounts/docs/OAuth2)
1. **アプリケーションを ID プロバイダーに登録します。**登録すると、プロバイダーからアプリケーションに固有の ID が提供されます。複数のアイデンティティプロバイダーで機能するようにアプリケーションを構築する場合は、各プロバイダーからアプリケーション ID を取得する必要があります。
1. **1 つ以上の IAM ロールを作成します。**各アプリケーションのアイデンティティプロバイダーごとに 1 つのロールが必要です。たとえば、ユーザーが Login with Amazon を使用してサインインするアプリケーションで想定できるロール、ユーザーが Facebook を使用してサインインする同じアプリケーションの 2 つ目のロール、およびユーザーが Google を使用してサインインするアプリケーションの 3 つ目のロールを作成します。
ロール作成プロセスの中で、 ポリシーをロールにアタッチする必要があります。ポリシードキュメントでは、アプリケーションに必要な DynamoDB リソース、およびそれらのリソースにアクセスするための許可を定義する必要があります。
詳細については、*IAM ユーザーガイド*の[ウェブ ID フェデレーションについて](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html)を参照してください。
**注記**
AWS Security Token Service の代わりに、Amazon Cognito を使用できます。Amazon Cognito は、モバイルアプリケーションの一時的な認証情報を管理するためのおすすめサービスです。詳細については、*Amazon Cognito 開発者ガイド*」の「[認証情報の取得](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-credentials.html)」を参照してください。
## DynamoDB コンソールを使用して IAM ポリシーを生成する
DynamoDB コンソールでは、ウェブ ID フェデレーションで使用する IAM ポリシーを作成できます。作成するには、DynamoDB テーブルを選択し、ポリシーに含まれるアイデンティティプロバイダー、アクション、および属性を指定します。DynamoDB コンソールによって、IAM ロールにアタッチすることができるポリシーが生成されます。
1. AWS マネジメントコンソール マネジメントコンソールにサインインして DynamoDB コンソール ([https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)) を開きます。
1. ナビゲーションペインで [**テーブル**] を選択します。
1. テーブルの一覧で、IAM ポリシーを作成するテーブルを選択します。
1. **[アクション]** ボタン、**[アクセス制御ポリシーの作成]** の順に選択します。
1. ポリシーの ID プロバイダー、アクション、および属性を選択します。
すべての設定が正しいことを確認したら、**[ポリシーの生成]** を選択します。生成されたポリシーが表示されます。
1. **[ドキュメンテーションを参照]** を選択し、生成されたポリシーを IAM ロールにアタッチするために必要な手順に従います。
# ウェブ ID フェデレーションを使用するアプリケーションの記述
ウェブ ID フェデレーションを使用するには、アプリケーションで、作成した IAM ロールを引き受ける必要があります。その時点から、アプリケーションは、そのロールに関連付けられたアクセスポリシーに従います。
実行時、アプリケーションがウェブアイデンティティフェデレーションを使用する場合、次の手順に従う必要があります。
1. **サードパーティーの ID プロバイダーと認証を行います。**アプリケーションは、ID プロバイダーが提供するインターフェイスを使用してそのプロバイダーを呼び出す必要があります。ユーザーを認証するときの正確な方法は、プロバイダーおよびアプリケーションを実行しているプラットフォームによって異なります。一般的に、ユーザーがまだサインインしていない場合、アイデンティティプロバイダーはそのプロバイダーのサインインページを表示するように対処します。
アイデンティティプロバイダーはユーザーを認証した後、ウェブアイデンティティトークンをアプリケーションに返します。このトークンの形式は、プロバイダーによって異なりますが、通常は、非常に長い文字列です。
1. **一時的な AWS セキュリティ認証情報を取得します。**取得するために、アプリケーションは `AssumeRoleWithWebIdentity` リクエストを AWS Security Token Service (AWS STS) に送信します。このリクエストには次のものが含まれます。
+ 前の手順からのウェブアイデンティティトークン
+ アイデンティティプロバイダーからのアプリケーション ID
+ このアプリケーションのこのアイデンティティプロバイダー用に作成した IAM ロールの Amazon リソースネーム (ARN)
AWS STS は、一定の時間 (デフォルトでは、3,600 秒) 経過した後に失効する AWS セキュリティ認証情報のセットを返します。
次に、`AssumeRoleWithWebIdentity` で AWS STS アクションを実行するときのサンプルリクエストとレスポンスを示します。ウェブアイデンティティトークンは、Login with Amazon アイデンティティプロバイダーから取得しました。
```
GET / HTTP/1.1
Host: sts.amazonaws.com
Content-Type: application/json; charset=utf-8
URL: https://sts.amazonaws.com/?ProviderId=www.amazon.com
&DurationSeconds=900&Action=AssumeRoleWithWebIdentity
&Version=2011-06-15&RoleSessionName=web-identity-federation
&RoleArn=arn:aws:iam::123456789012:role/GameRole
&WebIdentityToken=Atza|IQEBLjAsAhQluyKqyBiYZ8-kclvGTYM81e...(remaining characters omitted)
```
```
amzn1.account.AGJZDKHJKAUUSW6C44CHPEXAMPLE
AQoDYXdzEMf//////////wEa8AP6nNDwcSLnf+cHupC...(remaining characters omitted)
8Jhi60+EWUUbbUShTEsjTxqQtM8UKvsM6XAjdA==
2013-10-01T22:14:35Z
06198791C436IEXAMPLE
arn:aws:sts::123456789012:assumed-role/GameRole/web-identity-federation
AROAJU4SA2VW5SZRF2YMG:web-identity-federation
c265ac8e-2ae4-11e3-8775-6969323a932d
```
1. **AWSリソースにアクセスする** AWS STS からのレスポンスには、DynamoDB リソースにアクセスするためにアプリケーションに必要な情報が格納されています。
+ `AccessKeyID`、`SecretAccessKey`、および `SessionToken` フィールドには、このユーザーとこのアプリケーションにのみ有効なセキュリティ認証情報が入っています。
+ `Expiration` フィールドは、この認証情報の時間制限を示します。この時間を経過すると、認証情報は無効になります。
+ `AssumedRoleId` フィールドには、アプリケーションによって想定されたセッション固有の IAM ロールの名前が含まれています。アプリケーションは、このセッションの期間中、IAM ポリシードキュメントのアクセス制御に従います。
+ `SubjectFromWebIdentityToken` フィールドには、この特定のアイデンティティプロバイダー用の IAM ポリシー変数に表示される一意の ID が含まれています。次に、サポートされるプロバイダーの IAM ポリシー変数と、その値の例を示します。
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/WIF.RunningYourApp.html)
このポリシー変数が使用される IAM ポリシーの例については、[ポリシー例: きめ細かなアクセスコントロールのための IAM ポリシー条件の使用](specifying-conditions.md#FGAC_DDB.Examples) を参照してください。
AWS STS が一時的なアクセス認証情報を生成する詳しい方法については、*IAM ユーザーガイド*の[一時的なセキュリティ認証情報のリクエスト](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html)を参照してください。