Zenn
📝

1 つの Cognito ユーザープールに 2 つの ALB を紐づけた際のログインの挙動を確認してみた

に公開
AWS
alb
Cognito
tech

結論

  • 1 つの ALB で認証することで他方の ALB での認証は不要
  • ALB ごとに認証するためにはユーザープールを分割する必要がある

前提

  • ACM で証明書発行済み

Cognito ユーザープールの初期設定

Application Load Balancer を Amazon Cognito と統合してユーザーを認証する | AWS re:Post
リソースの構築は上記ナレッジセンターの内容で実施しました。

  • Cognito ユーザープール: サインイン識別子のオプションでメールアドレスを選択

  • アプリケーションクライアント

    • 1 つ目: ユーザープール作成時のクライアント
    • 2 つ目: デフォルト設定で作成

  • マネージドログインのスタイル

    • 1 つ目: ユーザープール作成時のスタイル
    • 2 つ目: 2 つ目のクライアントを指定してデフォルト設定で作成

  • Cognito ユーザー: メールアドレスを入力して作成

ALB の作成

ほとんどデフォルト設定ですが、HTTP では Cognito の認証を仕様できないため、プロトコルは HTTPS で作成します。

ターゲットグループは後で削除するのでデフォルト設定で作成したもので OK です。
同様に 2 つ目の ALB も作成しました。

リスナーの設定

各 ALB で別々のアプリケーションクライアントを選択します。

  • プロトコル: HTTPS
  • ユーザー認証: オン
    • アイデンティティプロバイダー: Amazon Cognito
    • ユーザープール: 作成済みのユーザープール
    • ユーザープールドメイン: 作成済みのユーザープールのドメイン
    • アプリケーションクライアント: 作成済みのクライアント
  • アクションのルーティング
    • 固定レスポンスを返す: 任意の内容で OK
  • デフォルト SSL/TLS サーバー証明書
    • ACM で発行済みの証明書

アプリケーションクライアントの設定変更

マネージドログインの許可されているコールバック URL を各 ALB のドメイン名に変更します。
1 つ目のアプリケーションクライアントには 1 つ目の ALB のドメイン名、2 つ目のアプリケーションクライアントには 2 つ目の ALB のドメイン名を指定します。

動作確認

1 つ目の ALB のドメイン名に HTTPS でアクセスし、作成済みのユーザーでログインします。
初回ログインではパスワードの変更を求められますが、パスワード変更後にログインできれば OK です。

続いて 2 つ目の ALB のドメイン名に HTTPS でアクセスすると、サインイン済みのユーザーで認証する画面が表示されました。

サインインを続行すると 2 つ目の ALB の固定レスポンスが表示されました。

以上より、1 つの ALB でサインイン状態が共有される挙動を確認できました。
なお、ALB とユーザープールを 1:1 にすることでサインイン状態が共有されることはありませんでした。

まとめ

今回は 1 つの Cognito ユーザープールに 2 つの ALB を紐づけた際のログインの挙動を確認してみました。
どなたかの参考になれば幸いです。

参考資料

Discussion