翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Application Load Balancer を使用してユーザーを認証する
Application Load Balancer を設定して、ユーザーがアプリケーションにアクセスしたときに安全に認証できます。これにより、アプリケーションがビジネスロジックに集中できるように、ユーザーを認証する作業をロードバランサーに任せることができます。
次にユースケースがサポートされています。
+ OpenID Connect (OIDC) に準拠する ID プロバイダー (IdP) を使用してユーザーを認証します。
+ Amazon、FaceBook、または Google などのソーシャル IdP を介して、Amazon Cognito でサポートされているユーザープールを経由して、ユーザーを認証します。
+ 企業アイデンティティを介して、SAML、OpenID Connect (OIDC) や OAuth、さらには Amazon Cognito がサポートするユーザープールを経由して、ユーザーを認証します。
## OIDC 準拠 IdP を使用する準備を整える
Application Load Balancer で OIDC 準拠 IdP を使用している場合は、以下を実行します。
+ IdP に新しい OIDC アプリを作成します。IdP の DNS はパブリックに解決可能でなければなりません。
+ クライアント ID およびクライアントシークレットを設定する必要があります。
+ その IdP によって発行される次のエンドポイントを取得します。認可、トークン、およびユーザー情報。この情報は config で確認できます。
+ IdP エンドポイント証明書は、信頼できる公開認証機関によって発行されている必要があります。
+ エンドポイントのDNSエントリは、プライベートIPアドレスに解決される場合でも、パブリックに解決できる必要があります。
+ IdP アプリで次のリダイレクト URL のいずれかを許可します。ユーザーが使用するものであればどれでも構いません。ここで DNS はロードバランサーのドメイン名であり、CNAME はアプリケーションの DNS エイリアスです。
+ https://*DNS*/oauth2/idpresponse
+ https://*CNAME*/oauth2/idpresponse
## Amazon Cognito を使用する準備を行う
### 利用できるリージョン
Application Load Balancer の Amazon Cognito 統合は次のリージョンでご利用いただけます。
+ 米国東部 (バージニア北部)
+ 米国東部 (オハイオ)
+ 米国西部 (北カリフォルニア)
+ 米国西部 (オレゴン)
+ カナダ (中部)
+ カナダ西部 (カルガリー)
+ 欧州 (ストックホルム)
+ 欧州 (ミラノ)
+ 欧州 (フランクフルト)
+ 欧州 (チューリッヒ)
+ 欧州 (アイルランド)
+ 欧州 (ロンドン)
+ 欧州 (パリ)
+ 欧州 (スペイン)
+ 南米 (サンパウロ)
+ アジアパシフィック (香港)
+ アジアパシフィック (東京)
+ アジアパシフィック (ソウル)
+ アジアパシフィック (大阪)
+ アジアパシフィック (ムンバイ)
+ アジアパシフィック (ハイデラバード)
+ アジアパシフィック (シンガポール)
+ アジアパシフィック (シドニー)
+ アジアパシフィック (ジャカルタ)
+ アジアパシフィック (メルボルン)
+ 中東 (アラブ首長国連邦)
+ 中東 (バーレーン)
+ アフリカ (ケープタウン)
+ イスラエル (テルアビブ)
Application Load Balancer でAmazon Cognito ユーザープールを使用している場合は、以下を実行します。
+ ユーザープールを作成します。詳細については、*Amazon Cognito デベロッパーガイド*の [Amazon Cognito user pools](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools.html)を参照してください。
+ ユーザープールのクライアントを作成します。クライアントシークレットを生成し、コード付与フローを使用し、ロードバランサーが使用するものと同じ OAuth スコープをサポートするように、クライアントを設定する必要があります。詳細については、*Amazon Cognito デベロッパーガイド*の [Configuring a user pool app client](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-client-apps.html) を参照してください。
+ ユーザープールのドメインを作成します。詳細については、「*Amazon Cognito デベロッパーガイド*」の「[ユーザープールドメインの設定](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-assign-domain.html)」を参照してください。
+ リクエストされたスコープで ID トークンが返されていることを確認します。たとえば、デフォルトのスコープ `openid` では ID トークンが返されますが、`aws.cognito.signin.user.admin` スコープでは返されません。
+ ソーシャルまたは企業 IdP と連携するには、フェデレーションセクションで IdP を有効にします。詳細については、「*Amazon Cognito デベロッパーガイド*」の「[サードパーティー ID プロバイダー経由のユーザープールへのサインイン](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-identity-federation.html)」を参照してください。
+ Amazon Cognito のコールバック URL フィールドで次のリダイレクト URL のいずれかを許可します。ここで DNS はロードバランサーのドメイン名であり、CNAME はアプリケーションの DNS エイリアス (使用している場合) です。
+ https://*DNS*/oauth2/idpresponse
+ https://*CNAME*/oauth2/idpresponse
+ IdP アプリのコールバック URL でユーザープールドメインを許可します。IdP の形式を使用します。以下に例を示します。
+ https://*domain-prefix*.auth.*region*.amazoncognito.com/saml2/idpresponse
+ https://*user-pool-domain*/saml2/idpresponse
アプリクライアント設定のコールバック URL はすべて小文字を使用する必要があります。
特定ユーザーが Amazon Cognito を使用してユーザーを認証するようにロードバランサーを設定するには、`cognito-idp:DescribeUserPoolClient` アクションを呼び出すアクセス許可をユーザーに付与する必要があります。
## Amazon CloudFront を使用する準備を行う
Application Load Balancer の前面で CloudFront ディストリビューションを使用している場合は、次の設定を有効にします。
+ 転送リクエストヘッダー (すべて) — CloudFront が認証されたリクエストに対する応答をキャッシュしないようにします。これにより、認証セッションが期限切れになった後にキャッシュから処理されるのを防ぎます。または、キャッシュが有効になっている間にこのリスクを軽減するために、CloudFront ディストリビューションの所有者は、認証 Cookie が期限切れになる前に有効期限 (TTL) の値を期限切れに設定することができます。
+ クエリ文字列の転送とキャッシュ (すべて) — ロードバランサーが、IdP を使用してユーザーを認証するために必要なクエリ文字列パラメータにアクセスできるようにします。
+ Cookie 転送 (すべて) — CloudFront がすべての認証 Cookie をロードバランサーに転送するようにします。
+ OpenID Connect (OIDC) 認証を Amazon CloudFront と組み合わせて設定する場合は、接続パス全体で HTTPS ポート 443 が一貫して使用されていることを確認してください。そうしないと、クライアント OIDC リダイレクト URL が最初に生成された URI のポート番号と一致しないため、認証が失敗する可能性があります。
## ユーザー認証を設定する
1 つ以上のリスナールールの認証アクションを作成して、ユーザー認証を設定します。`authenticate-cognito` および `authenticate-oidc` アクションタイプは HTTPS リスナーでのみサポートされています。対応するフィールドの説明については、*Elastic Load Balancing API リファレンスバージョン 2015-12-01* の [AuthenticateCognitoActionConfig](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_AuthenticateCognitoActionConfig.html) および [AuthenticateOidcActionConfig](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_AuthenticateOidcActionConfig.html) を参照してください。
ロードバランサーは、認証ステータスを維持するためにセッション Cookie をクライアントに送信します。ユーザー認証には HTTPS リスナーが必要であるため、この Cookie には常に `secure` 属性が含まれます。この Cookie には、CORS (クロスオリジンリソース共有) リクエストを持つ `SameSite=None` 属性が含まれています。
独立したクライアント認証を必要とする複数のアプリケーションをサポートしているロードバランサーについては、認証アクションがある各リスナールールに一意の cookie 名が必要です。これは、クライアントが常に IdP で認証されてから、ルールで指定されているターゲットグループにルーティングされることを確実にします。
Application Load Balancer は、URL エンコードされた Cookie 値をサポートしていません。
デフォルトでは、`SessionTimeout` フィールドは 7 日に設定されています。セッションをこれより短くするばあいは、セッションタイムアウトを最短 1 秒に設定できます。詳細については、「[セッションタイムアウト](#session-timeout)」を参照してください。
アプリケーションの必要に応じて、`OnUnauthenticatedRequest` フィールドを設定します。以下に例を示します。
+ **ユーザーがソーシャル ID または企業 ID を使用してログインする必要があるアプリケーション** — デフォルトのオプション `authenticate` でサポートされています。ユーザーがログインしていない場合は、ロードバランサーはリクエストを IdP 認可エンドポイントにリダイレクトし、IdP によってユーザーにユーザーインターフェイスを使用したログインを求めるプロンプトが表示されます。
+ **ログインしているユーザーにはパーソナライズされたビューを、ログインしていないユーザーには一般的なビューを提供するアプリケーション** — このタイプのアプリケーションをサポートするには、`allow` オプションを使用します。ユーザーがログインしている場合、ロードバランサーがユーザークレームを提供するため、アプリケーションはパーソナライズされたビューを提供できます。ユーザーがログインしていない場合、ロードバランサーはリクエストをユーザークレームなしで転送するため、アプリケーションは一般的なビューを提供できます。
+ **数秒ごとにロードされる JavaScript を使用した単一ページのアプリケーション** — `deny` オプションを使用すると、ロードバランサーは認証情報のない AJAX 呼び出しに対して HTTP 401 Unauthorized エラーを返します。ただし、ユーザーに有効期限の切れた認証情報がある場合は、クライアントを IdP 認可エンドポイントにリダイレクトします。
ロードバランサーは、IdP トークンのエンドポイント (`TokenEndpoint`) および IdP ユーザー情報エンドポイント (`UserInfoEndpoint`) と通信できる必要があります。Application Load Balancer は、これらのエンドポイントと通信するときのみ IPv4 をサポートします。IdP がパブリックアドレスを使用している場合は、ロードバランサーのセキュリティグループと VPC のネットワーク ACL が、それらのエンドポイントへのアクセスを許可していることを確認します。内部のロードバランサーまたは **IP アドレスタイプ** `dualstack-without-public-ipv4` を使用する場合、NAT ゲートウェイは、ロードバランサーがエンドポイントと通信することを可能にします。詳細については、*Amazon VPC ユーザーガイド* の [NAT ゲートウェイベーシック](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-basics) を参照してください。
次の [create-rule](https://docs.aws.amazon.com/cli/latest/reference/elbv2/create-rule.html) コマンドを使用して、ユーザー認証を設定します。
```
aws elbv2 create-rule \
--listener-arn listener-arn \
--priority 10 \
--conditions Field=path-pattern,Values="/login" \
--actions file://actions.json
```
`actions.json` ファイルの例を次に示します。`authenticate-oidc` アクションと `forward` アクション `AuthenticationRequestExtraParams` を使用すると、認証中に IdP に追加のパラメーターを渡すことができます。ID プロバイダーから提供されたドキュメントに従って、サポートされているフィールドを確認してください。
```
[{
"Type": "authenticate-oidc",
"AuthenticateOidcConfig": {
"Issuer": "https://idp-issuer.com",
"AuthorizationEndpoint": "https://authorization-endpoint.com",
"TokenEndpoint": "https://token-endpoint.com",
"UserInfoEndpoint": "https://user-info-endpoint.com",
"ClientId": "abcdefghijklmnopqrstuvwxyz123456789",
"ClientSecret": "123456789012345678901234567890",
"SessionCookieName": "my-cookie",
"SessionTimeout": 3600,
"Scope": "email",
"AuthenticationRequestExtraParams": {
"display": "page",
"prompt": "login"
},
"OnUnauthenticatedRequest": "deny"
},
"Order": 1
},
{
"Type": "forward",
"TargetGroupArn": "arn:aws:elasticloadbalancing:region-code:account-id:targetgroup/target-group-name/target-group-id",
"Order": 2
}]
```
`actions.json` アクションと `authenticate-cognito` アクションを指定する `forward` ファイルの例を次に示します。
```
[{
"Type": "authenticate-cognito",
"AuthenticateCognitoConfig": {
"UserPoolArn": "arn:aws:cognito-idp:region-code:account-id:userpool/user-pool-id",
"UserPoolClientId": "abcdefghijklmnopqrstuvwxyz123456789",
"UserPoolDomain": "userPoolDomain1",
"SessionCookieName": "my-cookie",
"SessionTimeout": 3600,
"Scope": "email",
"AuthenticationRequestExtraParams": {
"display": "page",
"prompt": "login"
},
"OnUnauthenticatedRequest": "deny"
},
"Order": 1
},
{
"Type": "forward",
"TargetGroupArn": "arn:aws:elasticloadbalancing:region-code:account-id:targetgroup/target-group-name/target-group-id",
"Order": 2
}]
```
詳細については、「[Application Load Balancer のリスナールール](listener-rules.md)」を参照してください。
## 認証のフロー
次のネットワーク図は、Application Load Balancer が OIDC を使用してユーザーを認証する方法を示しています。
![\[Application Load Balancer による OIDC を介したユーザーの認証方法\]](http://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/images/alb-user-auth-flow.png)
下の番号付き項目は、前のネットワーク図に示した要素を強調表示し、説明しています。
1. ユーザーは、Application Load Balancer の背後にホストされているウェブサイトに HTTPS リクエストを送信します。認証アクションを持つルールの条件が満たされている場合、ロードバランサーはリクエストヘッダーに認証セッション Cookie があるかどうかを確認します。
1. Cookie が存在しない場合、ロードバランサーはユーザーを IdP 認可エンドポイントにリダイレクトし、IdP でユーザーを認証できるようにします。
1. ユーザーが認証されると、IdP は認可付与コードを伴ったユーザーをロードバランサーにリダイレクトして戻します。
1. ロードバランサーは認可付与コードを IdP トークンエンドポイントに示します。
1. 有効な認可付与コードを受け取ると、IdP は ID トークンとアクセストークンをApplication Load Balancer に提供します。
1. 次に、Application Load Balancer がアクセストークンをユーザー情報エンドポイントに送信します。
1. ユーザー情報エンドポイントは、ユーザーの要求に対してアクセストークンを交換します。
1. Application Load Balancer は、`AWSELB` 認証セッション cookie を持つユーザーを元の URI にリダイレクトします。ほとんどのブラウザでは Cookie のサイズを 4K に制限しているため、ロードバランサーはサイズが 4K を超える Cookie を複数の Cookie に分割します。IdP から受け取ったユーザークレームとアクセストークンの合計サイズが 11K バイトを超える場合、ロードバランサーは HTTP 500 エラーをクライアントに返し、`ELBAuthUserClaimsSizeExceeded` メトリクスを増分します。
1. Application Load Balancer は Cookie を検証し、ユーザー情報を `X-AMZN-OIDC-*` HTTP ヘッダー設定のターゲットに転送します。詳細については、「[ユーザークレームのエンコードと署名の検証](#user-claims-encoding)」を参照してください。
1. ターゲットは応答をApplication Load Balancer に戻します。
1. Application Load Balancer は、最終応答をユーザーに送信します。
新しいリクエストはステップ 1 ～ 11 を通過し、後続のリクエストはステップ 9 ～ 11 を通過します。つまり、cookie の有効期限が切れていない限り、後続のすべてのリクエストはステップ 9 から始まります。
ユーザーが IdP で認証された後、`AWSALBAuthNonce` cookie がリクエストヘッダーに追加されます。これによって、Application Load Balancer が IdP からのリダイレクトリクエストを処理する方法が変わることはありません。
IdP によって ID トークンに有効な更新トークンが提供されている場合、ロードバランサーは更新トークンを保存し、アクセストークンの有効期限が切れるたびにこれを使用して、セッションがタイムアウトするか、IdP の更新に失敗するまで、ユーザークレームを更新します。ユーザーがログアウトすると、更新は失敗し、ロードバランサーはユーザーを IdP 認可エンドポイントにリダイレクトします。これにより、ロードバランサーはユーザーがログアウト後にセッションを削除できます。詳細については、「[セッションタイムアウト](#session-timeout)」を参照してください。
**注記**
cookie の有効期限は、認証セッションの有効期限とは異なります。cookie の有効期限は cookie の属性であり、7 日に設定されています。認証セッションの実際の長さは、認証機能用に Application Load Balancer で設定されたセッションタイムアウトによって決まります。このセッションタイムアウトは、認証 cookie 値に含まれ、暗号化されます。
## ユーザークレームのエンコードと署名の検証
ロードバランサーがユーザーの認証に成功すると、IdP から受け取ったユーザークレームがターゲットに送信されます。ロードバランサーはユーザークレームに署名するため、アプリケーションは署名の検証およびそのクレームがロードバランサーから送信されたものであることの検証を行うことができます。
ロードバランサーは以下の HTTP ヘッダーを追加します。
`x-amzn-oidc-accesstoken`
トークンエンドポイントからのアクセストークン (プレーンテキスト)。
`x-amzn-oidc-identity`
ユーザー情報エンドポイントからの件名フィールド (`sub`) (プレーンテキスト)。
**注:** サブクレームは、特定のユーザーを識別する最良の方法です。
`x-amzn-oidc-data`
ユーザークレーム (JSON ウェブトークン (JWT) 形式)
アクセストークンとユーザーの要求が、ID トークンと異なります。アクセストークンとユーザーの要求は、サーバーリソースへのアクセスのみを許可しますが、ID トークンはユーザーを認証するための追加情報を保持しています。Application Load Balancer は、ユーザーを認証するときに新しいアクセストークンを作成し、アクセストークンと要求のみをバックエンドに渡しますが、ID トークンの情報は渡しません。
これらのトークンは JWT 形式に従いますが、ID トークンではありません。JWT 形式には、base64 URL エンコードされたヘッダー、ペイロード、および署名が含まれ、末尾にパディング文字が含まれます。Application Load Balancer は ES256 (P-256 と SHA256 を使用する ECDSA) を使用して JWT 署名を生成します。
この JWT ヘッダーは、次のフィールドを持つ JSON オブジェクトです。
```
{
"alg": "algorithm",
"kid": "12345678-1234-1234-1234-123456789012",
"signer": "arn:aws:elasticloadbalancing:region-code:account-id:loadbalancer/app/load-balancer-name/load-balancer-id",
"iss": "url",
"client": "client-id",
"exp": "expiration"
}
```
この JWT ペイロードは、IdP ユーザー情報エンドポイントから受け取ったユーザークレームを含む JSON オブジェクトです。
```
{
"sub": "1234567890",
"name": "name",
"email": "alias@example.com",
...
}
```
ロードバランサーでユーザーの要求を暗号化する場合は、ターゲットグループで HTTPS を使用するように設定する必要があります。また、セキュリティのベストプラクティスとして、Application Load Balancer のトラフィックのみを受信するようにターゲットを制限することが推奨されます。ターゲットのセキュリティグループで、ロードバランサーのセキュリティグループ ID を参照するように設定するとこれを実行できます。
セキュリティを確保するには、要求に基づいて認証を行う前に署名を検証し、JWT ヘッダーの `signer` フィールドに、想定される Application Load Balancer ARN が記載されていることを確認します。
パブリックキーを取得するには、JWT ヘッダーからキー ID を取得し、それを使用して次のエンドポイントからパブリックキーを検索します: それぞれの AWS リージョンの場合、エンドポイントは次のとおりです:
```
https://public-keys.auth.elb.region.amazonaws.com/key-id
```
の場合 AWS GovCloud (US)、エンドポイントは次のとおりです。
```
https://s3-us-gov-west-1.amazonaws.com/aws-elb-public-keys-prod-us-gov-west-1/key-id
https://s3-us-gov-east-1.amazonaws.com/aws-elb-public-keys-prod-us-gov-east-1/key-id
```
AWS には、Amazon Cognito、Application Load Balancer、およびその他の OIDC 互換 IDP によって署名された JWTs を検証するために使用できるライブラリが用意されています。 IDPs 詳細については、「[AWS JWT トークンの検証](https://github.com/awslabs/aws-jwt-verify?tab=readme-ov-file)」を参照してください。
## タイムアウト
### セッションタイムアウト
更新トークンとセッションタイムアウトは連携して次のように動作します。
+ セッションタイムアウトがアクセストークンの有効期限より短い場合、ロードバランサーはセッションタイムアウトを優先させます。IdP とのセッションがまだアクティブであれば、ユーザーは再度ログインするように求められないことがあります。それ以外の場合、ユーザーはログインにリダイレクトされます。
+ IdP セッションタイムアウトが Application Load Balancer セッションタイムアウトよりも長い場合、ユーザーは再ログインするために認証情報を入力する必要はありません。代わりに、IdP は新しい認可付与コードを使用して Application Load Balancer にリダイレクトします。認可コードは、再ログインがない場合でも、一度の使用となります。
+ IdP セッションタイムアウトが Application Load Balancer セッションタイムアウト以下の場合、ユーザーは再ログインするための認証情報を指定する必要があります。再ログイン後、IdP は新しい認可コードを使用して Application Load Balancer にリダイレクトし、残りの認証フローはリクエストがバックエンドに到達するまで続行されます。
+ セッションタイムアウトがアクセストークンの有効期限よりも長く、IdP が更新トークンをサポートしていない場合、ロードバランサーは認証セッションをタイムアウトまで維持します。その後、ユーザーが再びログインします。
+ セッションタイムアウトがアクセストークンの有効期限よりも長く、IdP が更新トークンをサポートしている場合、ロードバランサーはアクセストークンの有効期限が切れるたびにユーザーセッションを更新します。ロードバランサーは、認証セッションがタイムアウトした後、または更新フローに失敗した場合にのみ、ユーザーに再度ログインさせます。
### クライアントログインのタイムアウト
クライアントは 15 分以内に認証プロセスを開始して完了する必要があります。クライアントは 15 分以内に認証を完了できなかった場合、ロードバランサーから HTTP 401 エラーを受信します。このタイムアウトは変更または削除できません。
例えば、ユーザーが Application Load Balancer を使用してログインページをロードする場合、15 分以内にログインプロセスを完了する必要があります。15 分間のタイムアウトの期限れ後にユーザーが待機してログインしようとすると、ロードバランサーが HTTP 401 エラーを返します。ユーザーはページを更新して、もう一度ログインする必要があります。
## 認証ログアウト
アプリケーションで認証済みユーザーをログアウトさせる必要がある場合、認証セッション Cookie の有効期限を -1 に設定し、クライアントを IdP ログアウトエンドポイントにリダイレクト (IdP でサポートされている場合) する必要があります。ユーザーが削除された Cookie を再利用しないようにするには、アクセストークンの有効期限を問題のない範囲でできるだけ短く設定することをお勧めします。有効期限切れのアクセストークンと null 以外の更新トークンがあるセッション Cookie を持つロードバランサーをクライアントが提供する場合、ロードバランサーは IdP に接続してユーザーがまだログインしているかどうかを判別します。
クライアントのログアウトランディングページは、認証されていません。つまり、認証を必要とする Application Load Balancer ルールの背後に存在することはできません。
+ リクエストがターゲットに送信されると、アプリケーションは、すべての認証 Cookie に対して有効期限を -1 に設定する必要があります。Application Load Balancer は、最大 16K のサイズの Cookie をサポートするため、クライアントに送信するシャードを最大 4 つ作成できます。
+ IdP にログアウトエンドポイントがある場合、IdP ログアウトエンドポイントへのリダイレクトを発行する必要があります。例えば、*Amazon Cognito デベロッパーガイド*に記載されている[ログアウトエンドポイント](https://docs.aws.amazon.com/cognito/latest/developerguide/logout-endpoint.html)。
+ IdP にログアウトエンドポイントがない場合、リクエストはクライアントのログアウトランディングページに戻り、ログインプロセスが再起動されます。
+ IdP にログアウトエンドポイントがあると仮定すると、IdP はアクセストークンを期限切れにしてトークンを更新し、ユーザーをクライアントのログアウトランディングページにリダイレクトし直す必要があります。
+ 後続のリクエストは、元の認証フローに従います。