翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Application Load Balancer を使用してユーザーを認証する

Application Load Balancer を設定して、ユーザーがアプリケーションにアクセスしたときに安全に認証できます。これにより、アプリケーションがビジネスロジックに集中できるように、ユーザーを認証する作業をロードバランサーに任せることができます。

OIDC 準拠 IdP を使用する準備を整える

Application Load Balancer で OIDC 準拠 IdP を使用している場合は、以下を実行します。

Amazon Cognito を使用する準備を行う

Application Load Balancer でAmazon Cognito ユーザープールを使用している場合は、以下を実行します。

アプリクライアント設定のコールバック URL はすべて小文字を使用する必要があります。

特定ユーザーが Amazon Cognito を使用してユーザーを認証するようにロードバランサーを設定するには、cognito-idp:DescribeUserPoolClient アクションを呼び出すアクセス許可をユーザーに付与する必要があります。

Amazon CloudFront を使用する準備を行う

Application Load Balancer の前面で CloudFront ディストリビューションを使用している場合は、次の設定を有効にします。

ユーザー認証を設定する

1 つ以上のリスナールールの認証アクションを作成して、ユーザー認証を設定します。authenticate-cognito および authenticate-oidc アクションタイプは HTTPS リスナーでのみサポートされています。対応するフィールドの説明については、Elastic Load Balancing API リファレンスバージョン 2015-12-01 の AuthenticateCognitoActionConfig および AuthenticateOidcActionConfig を参照してください。

ロードバランサーは、認証ステータスを維持するためにセッション Cookie をクライアントに送信します。ユーザー認証には HTTPS リスナーが必要であるため、この Cookie には常に secure 属性が含まれます。この Cookie には、CORS (クロスオリジンリソース共有) リクエストを持つ SameSite=None 属性が含まれています。

独立したクライアント認証を必要とする複数のアプリケーションをサポートしているロードバランサーについては、認証アクションがある各リスナールールに一意の cookie 名が必要です。これは、クライアントが常に IdP で認証されてから、ルールで指定されているターゲットグループにルーティングされることを確実にします。

Application Load Balancer は、URL エンコードされた Cookie 値をサポートしていません。

デフォルトでは、SessionTimeout フィールドは 7 日に設定されています。セッションをこれより短くするばあいは、セッションタイムアウトを最短 1 秒に設定できます。詳細については、「セッションタイムアウト」を参照してください。

アプリケーションの必要に応じて、OnUnauthenticatedRequest フィールドを設定します。以下に例を示します。

ロードバランサーは、IdP トークンのエンドポイント (TokenEndpoint) および IdP ユーザー情報エンドポイント (UserInfoEndpoint) と通信できる必要があります。Application Load Balancer は、これらのエンドポイントと通信するときのみ IPv4 をサポートします。IdP がパブリックアドレスを使用している場合は、ロードバランサーのセキュリティグループと VPC のネットワーク ACL が、それらのエンドポイントへのアクセスを許可していることを確認します。内部のロードバランサーまたは IP アドレスタイプ dualstack-without-public-ipv4 を使用する場合、NAT ゲートウェイは、ロードバランサーがエンドポイントと通信することを可能にします。詳細については、Amazon VPC ユーザーガイド の NAT ゲートウェイベーシック を参照してください。

次の create-rule コマンドを使用して、ユーザー認証を設定します。

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 のリスナールール」を参照してください。

認証のフロー

次のネットワーク図は、Application Load Balancer が OIDC を使用してユーザーを認証する方法を示しています。

下の番号付き項目は、前のネットワーク図に示した要素を強調表示し、説明しています。

新しいリクエストはステップ 1 ～ 11 を通過し、後続のリクエストはステップ 9 ～ 11 を通過します。つまり、cookie の有効期限が切れていない限り、後続のすべてのリクエストはステップ 9 から始まります。

ユーザーが IdP で認証された後、AWSALBAuthNonce cookie がリクエストヘッダーに追加されます。これによって、Application Load Balancer が IdP からのリダイレクトリクエストを処理する方法が変わることはありません。

IdP によって ID トークンに有効な更新トークンが提供されている場合、ロードバランサーは更新トークンを保存し、アクセストークンの有効期限が切れるたびにこれを使用して、セッションがタイムアウトするか、IdP の更新に失敗するまで、ユーザークレームを更新します。ユーザーがログアウトすると、更新は失敗し、ロードバランサーはユーザーを IdP 認可エンドポイントにリダイレクトします。これにより、ロードバランサーはユーザーがログアウト後にセッションを削除できます。詳細については、「セッションタイムアウト」を参照してください。

ユーザークレームのエンコードと署名の検証

ロードバランサーがユーザーの認証に成功すると、IdP から受け取ったユーザークレームがターゲットに送信されます。ロードバランサーはユーザークレームに署名するため、アプリケーションは署名の検証およびそのクレームがロードバランサーから送信されたものであることの検証を行うことができます。

アクセストークンとユーザーの要求が、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 Verify」を参照してください。

タイムアウト

セッションタイムアウト

更新トークンとセッションタイムアウトは連携して次のように動作します。

クライアントログインのタイムアウト

クライアントは 15 分以内に認証プロセスを開始して完了する必要があります。クライアントは 15 分以内に認証を完了できなかった場合、ロードバランサーから HTTP 401 エラーを受信します。このタイムアウトは変更または削除できません。

例えば、ユーザーが Application Load Balancer を使用してログインページをロードする場合、15 分以内にログインプロセスを完了する必要があります。15 分間のタイムアウトの期限れ後にユーザーが待機してログインしようとすると、ロードバランサーが HTTP 401 エラーを返します。ユーザーはページを更新して、もう一度ログインする必要があります。

認証ログアウト

アプリケーションで認証済みユーザーをログアウトさせる必要がある場合、認証セッション Cookie の有効期限を -1 に設定し、クライアントを IdP ログアウトエンドポイントにリダイレクト (IdP でサポートされている場合) する必要があります。ユーザーが削除された Cookie を再利用しないようにするには、アクセストークンの有効期限を問題のない範囲でできるだけ短く設定することをお勧めします。クライアントが、NULL 以外の更新トークンを持つ期限切れのアクセストークンを持つセッション Cookie をロードバランサーに提供する場合、ロードバランサーは IdP に連絡して、ユーザーがまだログインしているかどうかを判断します。

クライアントログアウトランディングページは認証されません。つまり、認証を必要とする Application Load Balancer ルールの背後にあることはできません。