BtoB SaaSにおけるテナント・ユーザー設計の悩みどころ

■イベント

BtoB SaaSにおける技術課題との向き合い方
https://sansan.connpass.com/event/263231/preview/

■登壇概要

タイトル：BtoB SaaSにおけるテナント・ユーザー設計の悩みどころ

登壇者：Sansan株式会社 Bill One Engineering Unit 加藤 耕太
ソフトウェアエンジニア。SIerを経て2018年にSansan入社。インボイス管理サービス「Bill One」のアーキテクトとして、技術選定から立ち上げに関わり、現在に至るまで開発および技術マネジメントに従事。 最近は Kotlin / TypeScript / React / Google Cloud をよく触っている。


■Sansan 技術本部 採用情報

https://media.sansan-engineering.com/

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

5. 話すこと
   ⁃ テナントとユーザーの関係
   ⁃ テナントと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
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

14. テナントとSSOの関係
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

22. まとめ
    

    View Slide

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

    View Slide

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

    View Slide

25. View Slide