1Passwordへの人の追加と削除は、管理コンソールで手動で行うか、IDプロバイダーと接続して任せるかのどちらかです。任せる場合は、1Passwordがホストする自動プロビジョニングと、自社で運用するSCIM Bridgeの2つの方式があります。どれを選ぶかは好みではなく、使っているIDプロバイダーでほぼ決まります。一方で、自動プロビジョニングは一度設定するとSCIM Bridgeに戻せず、Security Automationを使えるかどうかも分かれます。選び直しにくい判断なので、招待を始める前に確定させてください。このページでは、3つの方式の違い、IDプロバイダーごとの選び方、方式ごとに確かめること、既にSCIM Bridgeを運用している場合の扱いを説明します。IDプロバイダーごとの対応状況の一覧はIDプロバイダー別の対応状況で扱います。
3つの方式の違い
| 観点 | 手動 | 自動プロビジョニング | SCIM Bridge |
|---|---|---|---|
| 人を加える操作 | 管理コンソールの招待から招待する | IDプロバイダーで1Passwordを割り当てる | IDプロバイダーで1Passwordを割り当てる |
| 参加の確認 | 招待のパーミッションを持つ人が確認する | 本人が招待を受け入れた時点で確認される | SCIM Bridgeが通常5分以内に確認する |
| 退職時 | 管理者が一時停止または削除する | IDプロバイダーで外すと一時停止される | IDプロバイダーで外すと一時停止される |
| グループ | 1Passwordで作って管理する | IDプロバイダーのグループを同期する | IDプロバイダーのグループを同期する |
| 運用する基盤 | 不要 | 不要。アカウントと同じリージョンで1Passwordが運用する。Google Workspaceだけは同期のジョブを自社のGoogle Cloudに置く | 自社でデプロイし、更新を続ける |
どの方式を選んでも、サインインの方法は変わりません。IDプロバイダーでサインインさせるUnlock with SSOは別の統合で、使うかどうかはUnlock with SSOを使うかどうかの判断で決めます。
IDプロバイダーで方式はほぼ決まる
使える方式は、IDプロバイダーごとに決まっています。
Entra ID、Okta、JumpCloud、OneLogin、Google Workspaceの場合
この5つは自動プロビジョニングを使います。Entra ID、Okta、JumpCloud、OneLoginは、1Password側でSCIMのURLとベアラートークンを発行し、IDプロバイダーのアプリに設定すれば接続できます。Google Workspaceは、Googleのサービスアカウントを作り、自社のGoogle Cloudプロジェクトで同期のジョブを動かす形です。どれも自社でサーバーを運用する必要はありません。新しくSCIM Bridgeを立てる理由はないと考えてください。
Ripplingの場合
Ripplingは自動プロビジョニングに対応していません。自動化するなら、現時点ではSCIM Bridgeを使うしかありません。Rippling側でSCIM Bridgeをホストする選択肢もあります。
それ以外のIDプロバイダーの場合
上の6つ以外のIDプロバイダーと直接つなぐ方式は用意されていません。国内のIDプロバイダーを使っている場合もここに当たります。人の管理は手動で行い、入退社の連絡の流れで補います。サインインについては、OpenID Connectに対応していればUnlock with SSOを使える場合があるので、別に確かめてください。
手動で管理する場合
招待から、メールアドレス、サインアップリンク、Slackアプリの3つの方法で招待できます。メールの招待は5日で期限が切れ、いつでも送り直せます。サインアップリンクは取り消すまで有効で、許可ドメインのメールアドレスを持つ人なら誰でもアカウントを作れます。Slackアプリは、ワークスペースの人数が1,000人未満の場合に使えます。
どの方法でも、参加した人は確認が済むまで使い始められません。確認は、招待のパーミッションを持つ人が行います。手動の運用で抜けやすいのは退職時です。人事の連絡を誰が受け、何日以内に一時停止するかを決めておいてください。流れは招待と確認の流れと退職時の手順で扱います。
自動プロビジョニングを選ぶ前に確かめること
設定する前に、次の点を確かめます。
アカウントの復旧またはすべてのグループの管理を持つグループは、自動プロビジョニングの管理対象から外れます。所有者と管理者もこれに当たるので、メンバーは1Password側で手動で管理します- 許可ドメインに、gmail.comのような公開ドメインは登録できません。個人のアドレスで参加している人がいれば、先に会社のアドレスへ変更します
- 本人がメールアドレスを変えられなくなります。変更はIDプロバイダー側で行います
- 自動プロビジョニング用のグループが作られます。このグループには誰も入れません
- Security Automationを使えなくなります。使う予定があるなら、Security Automationと外部サービスの統合で先に判定します
【注意】 自動プロビジョニングを一度設定したアカウントでは、自己ホスト型のSCIM Bridgeに戻せません。方式の内部構造が違うためです。
SCIM Bridgeを選ぶ場合
SCIM Bridgeは将来廃止される予定です。新しく選ぶのは、Ripplingで自動化したい場合に限ります。
SCIM Bridgeは、Google Cloud PlatformやDigitalOceanなど自社の基盤にデプロイします。Azure Container Appsを使う場合を除き、公開のDNSレコードも必要です。SCIM Bridgeが止まっている間は同期が止まりますが、既存のアカウントと情報に影響はなく、デプロイし直してもデータは失われません。
SCIM Bridgeを運用する間は、デプロイ先、更新の担当、scimsessionファイルとベアラートークンの保管場所を記録しておきます。自動プロビジョニングへ移るときに、その記録が撤去の手順書になります。
既にSCIM Bridgeを運用している場合
Entra ID、Okta、JumpCloud、OneLogin、Google Workspaceと接続しているSCIM Bridgeは、自動プロビジョニングへ移行できます。移行すると、IDプロバイダーのアプリに新しいSCIMのURLとベアラートークンを設定し、SCIM Bridgeは撤去できます。Google Workspaceは、URLとトークンの代わりにGoogleのサービスアカウントで接続し直します。参加の確認も待ち時間がなくなります。
Google Workspace向けに構成したSCIM Bridgeでは、SCIMのインターフェイスが閉じられ、SaaS ManagerからEnterprise Password Managerへ接続できません。この構成を使っている組織は、移行の判断にこの点も含めてください。
移行の前に、今いる全員のメールアドレスのドメインが許可ドメインに入っていることを確かめてください。移行した後はSCIM Bridgeに戻せません。手順はSCIM Bridgeから自動プロビジョニングへの移行で扱います。