Sansan株式会社 技術本部 Bill One Engineering Unit 加藤耕太 BtoB SaaSにおけるテナント・ ユーザー設計の悩みどころ BtoB SaaSにおける技術課題との向き合い⽅

写真が⼊ります 加藤 耕太 Kota Kato Sansan株式会社 技術本部 Bill One Engineering Unit＠関⻄⽀店 Sansan株式会社所属のソフトウェアエンジニア。Sansan⼊社後 は営業DXサービス「Sansan」の開発を担当。その後インボイス 管理サービス「Bill One」のアーキテクトとして、技術選定から ⽴ち上げに関わり、現在に⾄るまで開発および技術マネジメント に従事。 最近は Kotlin / TypeScript / React / Google Cloud をよ く触っている。 著書：Pythonクローリング&スクレイピング データ収集・解析のための実践開発ガイド

営業DXサービス キャリアプロフィール インボイス管理サービス 名刺作成サービス 契約DXサービス

今⽇のゴール BtoB SaaSに特徴的な以下の2点を整理し、Bill Oneでの判断を紹介 ※SSO: Single Sign-On BtoB SaaSの設計・開発時に悩むことを少しでも減らしたい ⁃ テナントとユーザーの関係 ⁃ テナントとSSOの関係

話すこと ⁃ テナントとユーザーの関係 ⁃ テナントとSSOの関係 話さないこと ⁃ マルチテナントの実現⽅式やテナント間のデータの分離⽅法 ⁃ SSOの実装⽅法やIDaaSの利⽤⽅法 今⽇話すことと話さないこと 参考: SaaSにおけるマルチテナント設計の悩みと勘所 | SaaS.tech #2 – connpass https://saas-tech.connpass.com/event/243204/ マルチテナントSaaSのテナント分離をRow-Level Securityに移⾏した - Sansan Tech Blog https://buildersbox.corp-sansan.com/entry/2021/05/10/110000

テナントとユーザーの関係

アプリケーションで管理するリソースの論理的な境界 テナント内に複数のユーザーが存在するのが⼀般的 テナントとは クラウドサービス テナントA テナントB テナントC A社 B社 C社 ※1社1テナントが典型的だが それに限るものではない

テナントとユーザーの関係 3パターン テナント ユーザー 1 1..n テナント ユーザー 1..n 1..n 0..n テナント ユーザー 1..n ①テナントがユーザーを完全に管理 例：AWSのアカウントとIAMユーザー ②ユーザーは複数テナントに所属可能 例：Google Cloudのプロジェクト ③ユーザーはテナントに所属しないこともある 例：GitHubのOrganization

各パターンの特徴 ①テナントがユーザーを完全に管理 テナントが完全に管理したい場合に向いている ②ユーザーは複数テナントに所属可能 ユーザーを複数テナントに所属させたい場合には⾃然 ③ユーザーはテナントに所属しないこともある BtoCの要素が混在するサービスに向いている テナント ユーザー 1 1..n テナント ユーザー 1..n 1..n 0..n テナント ユーザー 1..n

請求書の受領サービスとして始まったBill Oneは、次のような仕様を選択 ⁃ 受領側のユーザーはテナントに所属する ⁃ 送付側のユーザーはテナントに所属しない ⁃ 受領側と送付側を兼ねることが可能 Bill Oneはパターン③を選択 テナント 受領側の ユーザー 1 1..n 送付側の ユーザー 初期の技術的な制約（テナント を気軽に増やせない）から来た 側⾯が⼤きいので、パターン② の⽅が楽だったかも ①テナントがユーザーを完全に管理 ②ユーザーは複数テナントに所属可能 ③ユーザーはテナントに所属しないこともある ユーザー アカウント 0..n 1 0..1 1

パターン①②の典型的なログイン画⾯ {tenant}.example.com ユーザー名 パスワード example.com テナントID ⼊⼒ テナントIDがわからない場合のフローがあると親切 例：メールアドレスを⼊⼒すると、テナントを選択するリンクが届く ※パターン①でユーザー名がサービス全体で⼀意の場合や、パターン②は次のページの⽅式でも可能 ログイン 次へ ①テナントがユーザーを完全に管理 ②ユーザーは複数テナントに所属可能 ③ユーザーはテナントに所属しないこともある

パターン②③の典型的なログイン画⾯ example.com ユーザー名 パスワード ※パターン②は前のページの⽅式でも可能 ログイン Bill Oneはこのログイン画⾯を採⽤ ①テナントがユーザーを完全に管理 ②ユーザーは複数テナントに所属可能 ③ユーザーはテナントに所属しないこともある

テナントに所属するユーザーが⽣成したデータは、ユーザー削除時ではなく テナント削除時に破棄するケースが多い 余談: テナントとユーザーのライフサイクル テナント ユーザー ユーザーA ユーザー ユーザーB ユーザーC 時刻 この時点では削除済みユーザーのデータとしてテナント内に残り続ける 利⽤終了時にテナント のデータをすべて破棄 利⽤開始 利⽤終了

テナントとSSOの関係

ユーザーが⼀度だけログイン処理をする ことで、複数のシステムを使えるように なる仕組み SaaSでは、以下のいずれかを使って IdP (Identity Provider) から認証情報を伝 達するのが⼀般的 ⁃ SAML (Security Assertion Markup Language) ⁃ OIDC (OpenID Connect) SSO (Single Sign-On) とは IdP サービスA サービスB サービスC

テナントとSSOの関係 3パターン テナント IdP 1..n 1 ユーザー IdP 1..n 1 A. テナントごとにIdPが決まる B-1. メールアドレスドメインごとにIdPが決まる B-2. ユーザーごとにIdPが決まる

A. テナントごとにIdPが決まる ユーザーのパターン①では⾃然だが、パターン②③で複数テナントに所属するユーザーや テナントに所属しないユーザーの認証⽅法は要検討 B-1. メールアドレスドメインごとにIdPが決まる ユーザーのパターン②③ではシンプルだが、メールアドレスドメインが同じでも異なるIdP を使っているケースに対応できない メールアドレスドメインを所有してることは要確認 B-2. ユーザーごとにIdPが決まる ユーザーのパターン②③で、メールアドレスドメインが同じでも異なるIdPを使っている ケースに対応できる 各SSOパターンの特徴 ①テナントがユーザーを完全に管理 ②ユーザーは複数テナントに所属可能 ③ユーザーはテナントに所属しないこともある

複数テナントに所属するためパターンAは使いづらく、IDaaSとして利⽤し ているAuth0のデフォルトの挙動を利⽤ メールアドレスドメインが同じでもSSOを使いたいテナントと使いたくな いテナントが存在するため、パターンB-2への移⾏を検討中 Bill OneはパターンB-1を採⽤ A. テナントごとにIdPが決まる B-1. メールアドレスドメインごとにIdPが決まる B-2. ユーザーごとにIdPが決まる

SSOパターンAの典型的なログイン画⾯ IdPの画⾯ ユーザー名 パスワード example.com テナントID ⼊⼒後に {tenant}.example.com 経由でリダイレクト 次へ ログイン A. テナントごとにIdPが決まる B-1. メールアドレスドメインごとにIdPが決まる B-2. ユーザーごとにIdPが決まる

SSOパターンB-1の典型的なログイン画⾯ IdPの画⾯ ユーザー名 パスワード example.com ⼊⼒後に リダイレクト メールアドレス 次へ ログイン Bill Oneはこの変化形として、パスワード⼊⼒欄があるロ グイン画⾯を採⽤しており、SSO対象ドメインのメールア ドレスを⼊⼒したタイミングでパスワード⼊⼒欄が消える A. テナントごとにIdPが決まる B-1. メールアドレスドメインごとにIdPが決まる B-2. ユーザーごとにIdPが決まる

SSOパターンB-2の典型的なログイン画⾯ IdPの画⾯ ユーザー名 パスワード example.com SSOを選んだとき だけリダイレクト メールアドレス パスワード SSO ログイン ログイン A. テナントごとにIdPが決まる B-1. メールアドレスドメインごとにIdPが決まる B-2. ユーザーごとにIdPが決まる

まとめ

以下のパターンを整理し、Bill Oneでの判断を紹介した テナントとユーザーの関係 3パターン ①テナントがユーザーを完全に管理 ②ユーザーは複数テナントに所属可能 ③ユーザーはテナントに所属しないこともある テナントとSSOの関係 3パターン A. テナントごとにIdPが決まる B-1. メールアドレスドメインごとにIdPが決まる B-2. ユーザーごとにIdPが決まる まとめ

Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/

No content