マルチテナント SaaS アプリケーションの認証を Amazon Cognito で実現してみよう !

マルチテナント SaaS における認証サービスの選択肢の一つとして、Amazon Cognito をご活用いただけます。Amazon Cognito にはユーザープールというユーザーディレクトリが用意されており、この中にアプリケーションのユーザープロファイルを格納できます。Amazon Cognito は クォータの範囲 内の一定のテナント数までであれば マルチテナントな使い方 もサポートしています。

マルチテナントな SaaS アプリケーションの認証・認可の実装においては、通常の Web アプリケーションの認証・認可に比べて下記のような追加の作り込みが必要となります。

• 新規テナント登録時のリソース作成 (オンボーディング)
• テナントごとの認証要件のカスタマイズ
• バックエンドアプリケーションでの複雑なアクセス制御
• テナント管理者によるユーザーやアイデンティティプロバイダー (IdP) の登録

マルチテナント戦略によって作るべきリソースは異なりますが、新規テナントがオンボーディングした際にはテナントごとにユーザープールやアプリケーションクライアントと呼ばれるリソースを作成する必要があります。また、バックエンドアプリケーションではテナント分離や契約プラン、ユーザーロールなどの複数の要素に基づいてアクセス制御を行う必要があります。アクセス制御においては、こちらの記事 で紹介している通り、各種 IdP やデータベースなどに点在しているこれらの情報を最初に JSON Web Token (JWT) に含んだ上でバックエンドに送ることで、バックエンド側の認可処理をシンプルに実現することができます。

では、通常の Web アプリケーションに比べて追加の労力が必要な開発を少しでも楽にするにはどうすれば良いでしょうか ? ここからは Amazon Cognito やライブラリの機能を活用して少しでも労力を減らすためのテクニックをご紹介します。

フロントエンドを JavaScript の各種フレームワークやモバイルアプリ等で開発する場合、AWS Amplify Libraries は Amazon Cognito との連携をするための最も有力な選択肢です。従来の Web アプリケーションではバックエンド側に認証の機能を実装するのが一般的でしたが、フロントエンドアプリケーションと Amazon Cognito が直接やり取りすることで、バックエンド側に認証のための API を持つ必要がなくなります。この際、Amplify Libraries を利用することで Amazon Cognito の API 呼び出しを抽象化し、認証後のトークンの管理など実装を簡略化することができます。

さらに、Amplify UI Components という組み込みのコンポーネントを使うことで認証のためのフォームをご自身で作る必要がなくなります。単純な ID、パスワードだけの認証であれば良いのですが、実際には MFA やパスワードリカバリー、メールアドレスの検証など、認証のワークフロー中のユーザーとのやり取りのための複数のフォームが必要となります。これに対し、 Amplify UI Components を利用することで、最初から上記のような画面遷移に対応したフォームが以下のような簡単なコードで簡単にアプリケーションに組み込めます。

下記のように、テーマカラーやフォームのスタイル、フォームの言語もカスタマイズも可能です。詳細はこちら をご覧ください。 

Amplify Libraries はユーザー名とパスワードや MFA を用いたログイン以外にもテナントの管理する外部 ID とのフェデレーションサインインも実装を大幅に抑えながら実現することが可能です。画面の実装をされる際はぜひ Amplify Libraries や Amplify UI Components のご利用をご検討ください。

SaaS 事業者は利用企業側の認証に関する要件にも対応していく必要があります。例えば他の顧客とユーザーの保存領域を明確に切り離したい、社内規定でパスワードポリシーが定まっていたり MFA を必須にする必要があるなどです。マルチテナントの環境でどこまで対応するかはビジネス戦略次第ですが、SaaS においては、上位プランを契約している要求の厳しい顧客のみ環境を分けるというデプロイオプション も検討いただけます。

Amazon Cognito でユーザーの認証要件をカスタマイズする場合、テナントごとにユーザープールを分けて実現する方法と、同じユーザープールの中でアプリケーションクライアントを分けることによって実現する方法があります。

テナント専用のユーザープールを作成することで、コンプライアンス上他テナントと同じ場所にパスワードを保存できないというテナントにも対応可能です。他にもパスワードポリシーをカスタマイズしたい、MFA を必須化したいなど、個別のテナントごとの要件にも柔軟に対応が可能です。さらに、ユーザープール単位で AWS WAF の ACL をアタッチできる ため、特定の IP アドレスからしか認証できないように制御するということも可能です。

認証要件の分離という観点ではわかりやすく、バックエンドアプリケーションもテナント専用に構築されている場合は認可も簡単に実現できます。一方で、バックエンドアプリケーションがマルチテナント構成の場合、動的に増えるユーザープールを識別して JWT を検証するロジックを作り込む必要があるため、実装が複雑になる可能性があります。

アプリケーションクライアントはユーザープールの API を呼び出すための認証情報です。同じユーザープールを利用している場合でも、このアプリケーションクライアントに紐づけて、

1. 外部 IdP を利用するか
2. パスワードログインを許可するか(認証フローのカスタマイズ) 
3. 各種トークンの有効期限

などをカスタマイズできます。

こちらはユーザープールが一つであるため、バックエンド側がシングルテナントであってもマルチテナントであっても COGNITO_USER_POOLS オーソライザー等を利用して、比較的シンプルに認可ロジックを実装できます。(別途テナントを分離するためのロジックは用意する必要があります。)

テナントごとに専用のユーザープールやアプリケーションクライアントを利用する場合、認証の前にテナントが利用する認証設定情報 (ユーザープール ID やアプリケーションクライアント ID) を取得した上で Amazon Cognito にリクエストを行う必要があります。この実現方法としてはいくつかありますが、例えばテナントごとにログインページのドメインを分けて、ドメインの値を元に認証設定情報を取得することが可能です。

フロントエンドアプリケーションで Amplify Library を用いる場合、バックエンドからダウンロードした設定情報を元に Amplify.configure() や Auth.configure() を呼び出すことで、動的にテナントごとの設定を切り替えることができます。下記の図は具体的な実装のイメージです。

これ以外にも、画面遷移として最初にテナント ID を入力させる方法や、メールアドレスを最初に入力させて所属するテナントの認証設定情報を取得する方法もあります。実現したい画面遷移に応じて最適なものを選んでいただければと思います。

前述の通り、アクセス制御に必要な情報を認証時に JWT に付与してアプリケーション全体に伝播することで、認証後のアプリケーション側でのアクセス制御のロジックをシンプルに実装することができます。

Amazon Cognito では JWT (ID トークン) に任意の属性を付与するための仕組みとして、カスタム属性 という機能が備わっています。最もシンプルな JWT のカスタマイズ方法としては、ユーザーのサインアップ時にテナント ID などのカスタム属性をイミュータブル（変更不可能）な属性として付与することです。

ただし、このカスタム属性は検索には利用できず、変更可能な値を入れる場合は、更新時に クォータ の影響を受ける可能性があります。

そこで、別のアプローチとして、Lambda 関数を用いて JWT に任意の属性を付与するということもできます。

トークン生成前の Lambda トリガーは認証成功時に Lambda 関数が呼び出され、JWT (ID トークン) の値を上書きすることができる仕組みです。これにより、Amazon Cognito のクォータを意識することなく DB 内部に保存されたテナントの契約プラン、ユーザーのロールなど変更される可能性のある情報も JWT に付与することが可能です。また、検索の要件がある場合も、DB 側に値が保持されているため、そこから検索を行うことができます。

本記事ではマルチテナントな SaaS アプリケーションに求められる要件と、Amazon Cognito を用いて SaaS の認証および、認可に用いる JWT のカスタマイズのテクニックをご紹介しました。

SaaS の認証においては、通常の Web アプリケーションに加えてオンボーディングや、テナントごとの認証要件のカスタマイズ、認可のロジックなどの検討すべき事項が存在します。これらの作り込みは比較的大変な作業になりがちですが、Amazon Cognito やライブラリの機能をうまく活用することで、実装に必要なコード量を削減することができます。本記事がこれからマルチテナントの認証を実装していく皆様の役に立てば幸いです。