管理者主導でユーザー登録を行う運用ケースでのAmazon Cognito ユーザープールを作成してみた

管理者主導でユーザー登録を行う運用ケースでのAmazon Cognito ユーザープールを作成してみた

Clock Icon2024.09.13

はじめに

本記事では、Amazon Cognitoを使用して、管理者が主導でAWSマネジメントコンソールからユーザー登録を行う運用を想定したユーザープールの作成方法を解説します。

この方法は、ユーザーが自由に新規登録するのではなく、管理者が招待したユーザーのみがアプリケーションを利用できるようにしたい場合に適しています。

構成は以下の通りです。

cm-hirai-screenshot 2024-09-06 15.56.24

管理者主導のユーザー登録運用でユーザープールを作成する際、設定項目によっては迷うことがありましたので、ご紹介します。

前提条件

本記事では、Cognitoユーザープールの作成に焦点を当てています。その他の環境構築については、以下の記事を参考に事前に完了していることを前提としています。

https://dev.classmethod.jp/articles/alb-ec2-cognito-hosted-ui-2023/

ユーザープールを作成

それでは、ユーザープールを作成します。

サインインオプションは、要件に応じて選択ください。
今回はユーザー名のみでのサインインを設定します。

cm-hirai-screenshot 2024-09-06 15.45.25

パスワードポリシーと多要素認証の設定は、セキュリティ要件に応じて調整可能です。

ユーザーアカウントの復旧機能(パスワードリセット)は、有効化はするとよいでしょう。理由は後述します。
復旧メッセージの配信方法は要件に応じて選択ください。今回はEメールのみとしました。

cm-hirai-screenshot 2024-09-09 15.49.04

管理者側でユーザー登録するため、自己登録は、無効必須です。

また、理由は後述しますが、検証メッセージの自動送信は無効すべきです。

追加の必須属性とカスタム属性は、デフォルトのままです。

cm-hirai-screenshot 2024-09-09 16.34.01

Eメールの送信方法には2つのオプションがありますが、どちらでもよいです。今回は[Cognito で E メールを送信]にします。

cm-hirai-screenshot 2024-09-06 15.45.45

Cognito Hosted UIは有効化必須です。これにより認証画面が提供されます。
ALBからCognito認証するため、クライアントシークレットの生成は必須です。

cm-hirai-screenshot 2024-09-06 15.48.56
cm-hirai-screenshot 2024-09-06 15.49.04

ユーザープール作成後、ALBにCognitoを統合しておきましょう。

ユーザーを作成

ここでは、ユーザーを作成してからメールでの招待までを解説します。

管理者がAWSマネジメントコンソール上のCognito ユーザープールからユーザーを作成します。

cm-hirai-screenshot 2024-09-06 17.34.29

ユーザー名とEメールを記載し、Eメールで招待を送信します。
[E メールアドレスを検証済みとしてマークする]はチェック必須です。

ユーザーがパスワードをリセットする場合、検証済みのメールアドレスに対してのみ復旧メッセージが送信されます。チェックしない場合、ユーザー側でパスワードリセットができませんので、検証済みは必須になります。

cm-hirai-screenshot 2024-09-09 15.51.59

指定したメールアドレスにユーザー名と仮パスワードが送信されます。

cm-hirai-screenshot 2024-09-06 17.35.35

Eメールで招待しない場

Eメールで招待しない場合、仮パスワードは、[パスワードの設定]から管理者側で作成して、Eメール以外の別の方法でユーザーに伝える必要があります。

cm-hirai-screenshot 2024-09-09 16.05.12

仮パスワードを[パスワードの生成]にすると、管理者側で仮パスワードの値がわからないため、ユーザーに伝えることができません。

ログイン

それでは、新規作成されたユーザーでのログインをします。

ユーザー名と仮パスワードを入力します。

cm-hirai-screenshot 2024-09-09 16.28.37

初回ログイン時、自動的にパスワード変更を要求されます。パスワードポリシーに従って、新しいパスワードを設定します。

cm-hirai-screenshot 2024-09-06 17.36.12

MFAアプリケーションで登録します。
cm-hirai-screenshot 2024-09-06 17.36.49

設定後、アプリケーションにログインできます。

ログイン後のユーザーステータスは、以下の通りです。

  • 確認ステータス:確認済み
  • メールアドレス:検証済み

cm-hirai-screenshot 2024-09-09 15.55.19

ユーザーアカウントの復旧の設定

ユーザーアカウントの復旧機能(パスワードリセット)の設定は、今回有効にしています。

有効/無効の違いは以下の通りです。

  • 有効化
    • ユーザーが自身でパスワードをリセットできます。
    • Hosted UIから、開発なしでパスワードリセットできます。
  • 無効化
    • パスワードリセットは管理者が行いますので、管理者の負担が増加します。
    • AWSマネジメントコンソールでは、パスワードはリセットできません。管理者がパスワードをリセットできるように、AWS CLIで実行もしくは、アプリケーション側で画面を開発する必要があります。

AWSドキュメントにも記載がある通り、無効化の場合、パスワードリセットするためにAPIを呼び出しが必要なため、AWS CLIで実行もしくは、アプリケーション側で開発が必要です。

セルフサービスによるアカウントの復旧が無効になっている場合、ユーザーはパスワードの復旧リクエストを開始できません。ユーザーのパスワードをリセットするには、アプリケーション管理者は AWS の認証情報を使用して AdminResetUserPassword または AdminSetUserPassword API を呼び出す必要があります。
https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/how-to-recover-a-user-account.html

AWS CLIでの実行コマンドは以下の記事で紹介されています。

https://repost.aws/ja/knowledge-center/cognito-reset-password-with-aws-cli

ユーザーアカウントの復旧が有効な場合、Hosted UIにパスワードリセットするためのリンクが用意されます。

ユーザープールでパスワードを忘れた場合のオペレーションを許可します。ホストされた UI サインインページで、「パスワードを忘れた場合」のリンクが表示されます。この機能が有効になっていない場合、管理者は Cognito API を使用してパスワードをリセットします。

管理者側でユーザーを招待しているため、パスワードリセットはユーザー側で行えてもよいと思います。

そのため、特に要件がなければ、ユーザーアカウントの復旧機能は有効化するとよいでしょう。

ちなみに、ユーザー作成時、[E メールアドレスを検証済みとしてマークする]をチェックしない場合、パスワードリセット時に送信される復旧コードがメールアドレスに送信されませんので、検証済みにしておくことを忘れないようにしましょう。

検証メッセージの自動送信設定について

本記事で作成したユーザープールでは、検証メッセージの自動送信を無効にしています。
ここでは、この設定の影響と、有効化した場合の動作について説明します。

管理者が電話番号やメールアドレスを更新した際、検証メッセージを自動送信するかどうかを設定できます。
この設定は[Cognito アシスト型の検証および確認]項目で行います。

cm-hirai-screenshot 2024-09-09 15.07.22

この設定により、以下の違いが生じます。
ちなみに、検証メッセージと復旧メッセージは別物ですので、検証メッセージの自動送信の有効/無効は、復旧メッセージには影響しません。

  1. 自動送信が有効の場合:管理者がメールアドレスを変更すると、新しいアドレスに検証コードが自動送信されます。
  2. 自動送信が無効の場合:管理者がメールアドレスを変更しても、検証コードは送信されません。

しかし、Eメールアドレスの検証状態(検証済み/未検証)に関わらず、管理者がメールアドレスを修正した場合、検証コードが送信されても、ユーザーがそれを入力する手段(Hosted UI等)がないため、混乱を招く可能性があります。

よって、自動送信は無効でよいです。

この設定を無効にした場合と有効にした場合の具体的な挙動の違いを確認してみます。

自動送信無効の場合

AWSマネジメントコンソール上から、ユーザーのメールアドレスを変更してみます。

cm-hirai-screenshot 2024-09-09 16.56.14
変更後のメールアドレスには、検証コードは送信されません。

ユーザー名でのログインには影響ありません。
サインインオプションでEメールが有効な場合、変更後のメールアドレスでログインできます。

自動送信有効の場合

検証メッセージの自動送信を有効化します。

cm-hirai-screenshot 2024-09-09 15.07.22

同様にメールアドレスを変更してみます。

変更後のメールアドレスに、検証コードが送信されます。

cm-hirai-screenshot 2024-09-06 17.51.21

ただし、検証コードが送信されても、ユーザーがそれを入力する手段(Hosted UI等)が提供されておらずユーザーの混乱を招く可能性があるため、本構成において自動送信は無効でよいです。

サインインオプションでEメールが有効な場合、変更後のメールアドレスでログインできます。

[未完了の更新があるときに元の属性値をアクティブに保つ]

サインインオプションでEメールが有効な場合、検証メッセージの自動送信設定のうち[未完了の更新があるときに元の属性値をアクティブに保つ]を有効化すると、メールアドレス変更後、メールアドレスを検証済みになるまでは、変更後のメールアドレスでログインできません。

cm-hirai-screenshot 2024-09-09 15.06.41

最後

本記事では、Amazon Cognitoを使用して管理者主導でユーザー登録を行う運用を想定したユーザープールの作成方法を解説しました。主なポイントは以下の通りです。

  • 自己登録を無効にして、ユーザー側では新規登録できないようにする。
  • 検証メッセージの自動送信は無効にする。
  • 特に要件がなければ、ユーザーアカウントの復旧機能(パスワードリセット)は、有効化する。
    • パスワードリセットが有効化の場合、ユーザー作成時に「Eメールアドレスを検証済みとしてマークする」をチェックする

これらの設定により、管理者が招待したユーザーのみがアプリケーションにログインできる環境を容易に構築できます。

また、ユーザーのパスワードリセットや管理者によるメールアドレス変更時の挙動についても確認しました。

Cognitoの設定には多くのオプションがありますが、要件に応じて適切に選択することで、セキュアで管理しやすいユーザー認証システムを構築することができます。

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.