SaaS on AWS における認証認可の実装パターンとは ?

各種アイデンティティプロバイダー (IdP) やデータベースなどに散らばるこれらの情報を一元的に管理することができれば、複雑化しがちな認証・認可の実装のコストの軽減や、パフォーマンスの向上につなげることができますが、これはどのように実現することができるでしょうか ?

まずはコンセプトから見ていきましょう。

リクエストの送信元のユーザーがどのテナントに所属しているのか、そのテナントが契約しているプランは何か、そういったテナントにまつわる情報、今後はテナントコンテキストという呼び方をしますが、これを先に述べたような一元的な SaaS Identity として管理し、受け渡すやり方にはどのようなものがあるでしょうか ?

実はこれ、前回 の連載でも簡単にご紹介しているのですが、一つは JSON Web Token (JWT) を用いる方法があります。JWT とは、簡単に説明すると、クレームと呼ばれる属性情報を二者間で安全に受け渡しするための JSON ベースの形式について規定した仕組みのことで、RFC7519 としてオープン標準になっています。

この JWT を使った仕組みがどのように動作するかというと、まずユーザーの認証時に、所属するテナントの識別子 (ex. 一意のテナント ID) をカスタムクレームとして JWT に含め、クライアントに返却します。クライアント側は、毎回のリクエストでこの JWT を HTTP リクエストのヘッダーに含め、サーバー側に送信します。そしてサーバー側は必要に応じてトークンの検証を行い、パースして中身のクレームを取り出しテナント ID からテナントを識別するという流れになります。

また、このテナントコンテキストはログやメトリクス、メータリングにおいても活用できます。ログやメトリクスにテナントIDを埋め込むことによって、テナントごとの利用傾向の可視化や障害時の調査に役立てることができるのですが、これについては以降の連載の運用や分析の回でも取り上げますのでお楽しみに !

ここからは上で紹介した仕組みについて具体的な実装方法を見ていきましょう。

どの IdP を使うかによってそれぞれ異なる部分がありますが、今回は Amazon Cognito を例に考えていきます。Amazon Cognito は、独自のユーザーディレクトリを持ち、AWS Identity and Access Management (IAM) と組み合わせることで AWS リソースへのアクセス権限を管理することもできる認証・認可の機能を提供するサービスです。ソーシャルサインインや OpenID Connect (OIDC), SAML 準拠の IdP とのフェデレーションもサポートしています。

まずはユーザープールを作成します。これは Cognito のユーザーディレクトリで、ユーザーの管理、パスワードポリシーや MFA 、フェデレーションの設定などを行うことができます。

SaaS においては、このユーザープールをシングルテナントにするかマルチテナントにするかという検討事項があります。それぞれトレードオフがありますが、テナント分離の回で見たように、AWSリソースへのアクセスポリシーを細かく制御する必要がある、またはパスワードポリシーや MFA の設定をテナントごとに柔軟に変えたいというような要件がある場合は、テナントごとに個別のユーザープールを作成することをおすすめします。

ただしこの場合、認証リクエストが来た際にどのユーザープールに対して認証を行うかを判断する必要が出てきます。一つの方法としては、メールアドレスのドメインとそのテナントのユーザープールの対応表を Amazon DynamoDB のようなデータベースに保存しておき、リクエストの内容を見てどのユーザープールを使うのか判断するという方法が考えられます。

また、この方法は複数の IdP を用いる際も有用で、どの IdP を使うか前段でルーティングを行うことで、あるテナントでは Cognito、別のテナントではサードパーティの Auth0 を使うといった構成が可能になります。これは特に BtoB でよくあるケースですが、SaaS 利用者がすでに社内で利用している IdP があってそれをそのまま使いたいというようなケースでユーザーの要望に応えることができます。

下の図では、テナント 1 およびテナント 2 がオンプレミスで管理しているユーザーディレクトリを、他のテナントでは Amazon Cognito をアイデンティティストアとして利用するハイブリッドな構成例を示しています。Authentication manager がどのテナントがどの認証方法を用いるかを管理している Tenant configuration に問い合わせを行い、その設定に応じて認証とトークンの受け渡し処理を行います。

さて、次に Cognito によるトークンの取り扱いについて見ていきます。

ユーザープールに対してユーザーがメールアドレス、電話番号、パスワードなど (何を用いるかはユーザープールの設定による) で認証を行うと、成功時に 3 つのトークンが返却されます。OIDC オープン標準によって定義されている ID トークン、アクセストークン、リフレッシュトークンの 3 種類です。各トークンの詳細については こちらのドキュメント をご覧ください。

トークンにはそれぞれ OIDC で規定されているクレームがデフォルトで含まれていますが、ユーザープールの設定でカスタム属性を追加することができるので、テナント ID など使用する属性をあらかじめ設定しておきます (カスタム属性には、常に custom: プレフィックスが付与されます)。ユーザーのサインアップ時にはそれらの属性を含めてユーザーを登録します。

JWT の復号化と検証にはライブラリを使うことをおすすめします。
ID トークンとアクセストークンはそれぞれ異なる鍵で署名されていますが、Amazon Cognito SDK、Mobile SDK for iOS、Mobile SDK for Android を利用すると実装の手間を減らすことができます。

JWT の検証の詳細については JSON Web トークンの検証 をご覧ください。

いかがでしたでしょうか ?
マルチテナント SaaS においては、顧客のデータを保護するために特にセキュリティに関して気を配る必要がありますが、標準化された手段やマネージドサービスをうまく活用してリスクや実装の手間を削減していただければと思います。

次回の予定は「オンボーディング」です。テナントの登録、ユーザーの発行、インフラストラクチャのプロビジョニングなど、顧客が SaaS を契約してから利用できるようになるまでに、やらなければならないことはたくさんあります。このリードタイムの短さ、理想を言えば完全にセルフサービスで利用できることが SaaS のメリットの一つですが、これはどのように検討することができるでしょうか ?

ぜひ次回の連載もお楽しみに !