自動プロビジョニングは、IDプロバイダーの操作を1Passwordのアカウントに反映させる統合です。人の追加、属性の更新、退職時の一時停止、グループの同期を、IDプロバイダーの画面だけで済ませられます。接続先のサーバーは1Passwordが運用するので、自社でSCIM Bridgeを立てる必要はありません。一方で、一度設定すると元の方式に戻せず、アカウントの動き方もいくつか変わります。このページでは、できることとできないこと、1Passwordがホストしても暗号の鍵を渡さずに済む仕組み、設定すると変わること、IDプロバイダーごとの接続の形、始める前にそろえる前提を説明します。方式そのものを選ぶ段階なら、先に手動、自動プロビジョニング、SCIM Bridgeの比較を読んでください。
自動プロビジョニングでできること
IDプロバイダーで行った操作が、1Password側では次のように反映されます。
| IDプロバイダーでの操作 | 1Password側の結果 |
|---|---|
| 1Passwordを割り当てる | 招待のメールが届き、本人がサインアップすると自動で確認される |
| 名前やメールアドレスを変える | 1Password側の属性が変わる。メールアドレスは本人の確認で完了する |
| 無効化する、削除する、割り当てを外す | アカウントが一時停止される |
| 割り当てたグループの所属を変える | 1Password側のグループの所属が変わる |
反映されないものもあります。サインインの方法は変わりません。IDプロバイダーのアカウントでロックを解除させたい場合は、Unlock with SSOを別に設定します。アカウントの完全な削除は、一時停止の後に1Password側で行います。保管庫へのアクセス権や、個別に渡した共有もIDプロバイダーからは動かせません。IDプロバイダーが決めるのは、誰がどのグループにいるかまでです。
1Passwordがホストしても鍵を渡さずに済む仕組み
人を追加して確認するには、暗号の鍵を扱う処理が要ります。以前はこの処理を自社の基盤に置くSCIM Bridgeが担っていました。自動プロビジョニングは同じ処理を1Passwordの基盤で動かしながら、1Password社にもクラウド事業者にも鍵の中身が見えない形にしています。支えているのは3つの仕組みです。
鍵を扱う処理を隔離された環境で動かす
鍵を扱う処理は、AWS Nitro Enclavesを使ったコンフィデンシャルコンピューティングの環境で動きます。1Passwordの他のシステムから切り離されており、1Password社が中のソフトウェアや鍵に直接触れられない構成です。
公開鍵が本物かどうかを確かめる
SCIM Bridgeは、1Passwordのサーバーから受け取った公開鍵をそのまま信用していました。サーバーが乗っ取られて偽の鍵を返されても、見分ける手段がありません。自動プロビジョニングはAccount Trust Logという署名の連なりで、処理の前に全ての公開鍵を検証します。Account Trust Logの起点は、最初に設定した管理者の操作で作られます。
招待できるドメインを署名で固定する
設定した時点の許可ドメインが署名されます。新しい人を作るときと、メールアドレスを変えるときに、この署名と突き合わせます。サーバー側で許可ドメインを書き換えられても、署名のないドメインの人は作られません。
設定すると変わること
自動プロビジョニングを設定すると、アカウントの動き方が次のように変わります。
| 対象 | 設定後の動き |
|---|---|
| 参加の確認 | 本人が招待を受け入れた時点で確認される。管理者の承認は要らない |
| メールアドレスの変更 | 本人は変えられない。IDプロバイダーで変え、本人が確認する |
| 管理者のグループ | アカウントの復旧かすべてのグループの管理を持つグループは管理対象から外れる。所有者と管理者も外れる |
| 新しいグループ | Provision Managersが作られる。削除できず、原則として誰も入れない |
| SCIM Bridge | このアカウントでは今後使えない |
| Security Automation | 使えない |
| 1Password CLIでの人の管理 | 2.36.0-beta.02以降でだけ使える |
管理者のグループが外れるのは、IDプロバイダーが侵害されたときに、アカウント全体の鍵に届かせないためです。復旧を担う人の出入りは、1Password側で手動で管理します。
IDプロバイダーごとの接続の形
接続できるIDプロバイダーは5つです。Google Workspaceだけ、つなぎ方が違います。
| IDプロバイダー | つなぎ方 | 反映の流れ |
|---|---|---|
| Microsoft Entra ID、Okta、JumpCloud、OneLogin | 1Passwordが発行するSCIMのURLとベアラートークンを、IDプロバイダーのアプリに入れる | IDプロバイダーが1Passwordに変更を送る |
| Google Workspace | Googleのサービスアカウントを作り、自社のGoogle Cloudプロジェクトで同期のジョブを動かす | 追加は1時間ごと、外した人とグループはすぐに反映される |
Entra IDは約40分の周期で変更を送ります。反映の早さはIDプロバイダーの側で決まるので、問い合わせを受けたら先にその周期を確かめてください。手順はMicrosoft Entra IDとの統合、Oktaとの統合、JumpCloudとOneLoginとの統合、Google Workspaceとの統合で扱います。
始める前にそろえる前提
設定する人は、所有者か管理者グループに属している必要があります。IDプロバイダー側でも、アプリを追加できる管理者の役割が要ります。
許可ドメインは、設定の前に全て登録しておきます。署名されるのは設定した時点の一覧で、空欄のままだとどのドメインの人でも作られます。子会社のドメインや別名のドメインも漏らさないでください。gmail.comのような公開ドメインは登録できません。
既にメンバーがいる場合は、1Passwordのメールアドレスと、IDプロバイダーのメールアドレスをそろえます。一致した人は紐づき、一致しない人には招待が改めて届きます。
【注意】 SCIM Bridgeに戻れなくなるのは、自動プロビジョニングを設定した時点です。どの操作をもって設定したとみなされるかは、画面では示されません。方式を決める前に、本番のアカウントで試しにセットアップを始めないでください。
設定の流れを確かめたい場合は、IDプロバイダーのテスト用のユーザーを1人だけ割り当てる形で始めます。組織全体をいきなり割り当てず、段階的に広げる進め方はプロビジョニング運用の設計で扱います。