$30 off During Our Annual Pro Sale. View Details »

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

Sansan
December 12, 2022

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/

Sansan

December 12, 2022
Tweet

More Decks by Sansan

Other Decks in Technology

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