BtoB SaaSにおけるテナント・ユーザー設計の悩みどころ／Sansan株式会社 ソフトウェアエンジニア 加藤耕太氏
次に登壇したのはSansan株式会社の加藤耕太氏。加藤氏は、あらゆる請求書をオンラインで受け取り、企業全体の月次決算を加速するインボイス管理サービス「Bill One」のアーキテクトを務めている。テナントとユーザー、そしてユーザーの認証はBtoB SaaSにおいて頻出する概念だ。このセッションでは、テナント・ユーザー関連の設計パターンやその特徴、そして「Bill One」の選んだ方針が語られた。
テナントとユーザーの関係性としては、代表的なものが3パターン挙げられる。1つ目が「①テナントがユーザーを完全に管理する」パターン。これはAWSにおけるアカウントとIAMユーザーのように、テナントとユーザーが1対1..nで紐づく。2つ目が「②ユーザーが複数テナントに所属可能である」パターン。Google Cloudのプロジェクトのように、テナントとユーザーが1..n対1..nで紐づく。3つ目が「③ユーザーはテナントに所属しないこともある」パターン。GitHubのOrganizationのように、テナントとユーザーが0..n対1..nで紐づく。
各パターンの特徴として、①はテナントがユーザーを完全に管理したい場合に、②はユーザーを複数テナントに所属させたい場合に、③はBtoCの要素が混在するサービスの場合に向いている。セッション内では「Bill One」ではパターン③を選択していることと、その理由が語られた。
次に、テナントとSingle SignOn（以下、SSO）の関係性についても解説された。SaaSではSAML（Security Assertion Markup Language）またはOIDC（OpenID Connect）のいずれかを使って、Identity Provider（以下、IdP）から認証情報を受け取るのが⼀般的だ。テナントとSSOの関係性も、代表的なものとして3パターンが挙げられる。
まずは「A. テナントごとにIdPが決まる」パターン。これは、前述のユーザーのパターン①においては⾃然な設計だが、パターン②③で複数テナントに所属するユーザーやテナントに所属しないユーザーの認証⽅法は要検討となってしまう。次に「B-1. メールアドレスドメインごとにIdPが決まる」パターン。これは前述のユーザーのパターン②③ならばシンプルな設計になるが、メールアドレスドメインが同じで異なるIdPを使っているケースに対応できない。加えて「B-2. ユーザーごとにIdPが決まる」パターン。これは前述のユーザーのパターン②③において、メールアドレスドメインが同じで異なるIdPを使っているケースに対応できる。
「Bill One」はパターンB-1を採⽤しているが、パターンB-2への移⾏を検討中だという旨が述べられた。「こうした設計パターンを、ぜひプロダクト開発の際に参考にしてほしい」と加藤氏はセッションを締め括った。
