B2B SaaS におけるプロビジョニング

これは、Calendar for SmartHRの村だよ | Advent Calendar 2021 - Qiita 17日目の記事です。

B2B SaaS のアカウント管理にもとめられるもの

  • 必要なタイミングで必要とする従業員へ付与
  • 不要となったタイミングで剥奪

アカウント発行/SSO

  • SaaS毎に認証・アカウント発行をすると付与漏れ、剥奪漏れが起きる
  • IdPを中心にアカウントの発行・剥奪が行われる
  • 利用者は IdPでのSSOで対象のSaaSを利用する

プロビジョニング

  • アカウント発行・剥奪の自動化のためのプロビジョニング
  • 通常のSaaSにおいては、
    • IdPにアカウントがある前提
    • IdPにアカウントがあり新規発行されるアカウントは各SaaSにプロビジョニングされアカウントが作られる
    • 権限付与は対象のユーザーの属性によって管理されたりする

SCIM

OIDF-J の WGによる資料

従業員の情報の源泉

  • 新しく社員が入社し、その対象の従業員の情報を得るタイミングはどこになるか
  • 人事チームなどが握っている情報
    • 人事チームが管理するHRシステムなどにまず情報が登録される
  • IdPにどのタイミングで付与されるのか
    • 人事チームから情シスチームなどに情報が伝搬され IdPのアカウントや社用のメアドなどが発行される
  • IdPが アカウント管理の中心にはいることとになるが、その源泉たる従業員の情報は HRシステムが最初に持つことは多いと思われる

入社時のフロー概念

入社時のフロー概念
入社時のフロー概念

退職時のフロー概念

退職時のフロー概念
退職時のフロー概念

入社情報と退職情報を適切に捉える必要がある

  • データの源泉となるところを起点とする方がよさそう
  • HR Driven Provisioning と呼ばれる概念
  • 従業員の入退社のイベントを捉えてprovisioningをする

SmartHRの例

  • SmartHR のアカウントは入社前に発行されて退職後も使って欲しいという思想で出来ている
    • 入社時に情報を入力・確認してもらう
    • 退職後も在職期間中に発行された情報を閲覧する
  • IdPとの連携は SAML/SSO機能として 2019年にリリースしているが、SSOのところのみをサポート
    • プロビジョニングに関しては、要望をもらっていたものの、IdPとどちらのアカウントが先に発行されるべきなのかの結論が出ずpend状態
  • Okta社からの提案で Provisioningの featureの実装を再開 (2021/07)
    • HR Driven Provisioning でデータの源泉となるものを SmartHRから Oktaへインポートする
    • Oktaでアカウントが発行されると SmartHRへ Okta経由で SSOできるようになる
    • closed beta扱いで SmartHR社でのテストを実施予定

まとめ

  • B2B SaaS における ProvisioningとSSOは正義
  • HR Driven Provisioningによって従業員情報のデータの源泉を抑えると良いことがあるかもしれない
  • おわり