自己ホスト型のSCIM Bridgeを使っている組織が、1Passwordがホストする自動プロビジョニングへ切り替える手順です。移行できるのは、Entra ID、Okta、JumpCloud、OneLogin、Google Workspaceと接続している場合です。作業そのものは、1Password側で新しい接続情報を作り、IDプロバイダーのアプリに入れ直すだけで終わります。ただし移行すると元に戻せず、アカウントの動き方もいくつか変わります。このページでは、移行すると変わること、移行の前にそろえること、1Password側の切り替え、IDプロバイダー側の接続情報の差し替え、SCIM Bridgeの撤去を説明します。
移行すると変わること
移行すると、次の点が変わります。
| 対象 | 移行後 |
|---|---|
| 運用する基盤 | 1Passwordが、アカウントと同じリージョンで運用する。EUのアカウントならEUで動く |
| IDプロバイダーとの接続 | 新しいSCIMのURLとベアラートークンで接続し直す。Google WorkspaceはGoogleのサービスアカウントで接続する |
| 参加の確認 | 5分の待ち時間がなくなり、本人が確認の流れを終えた時点で確認される |
| 管理者のグループ | アカウントの復旧かすべてのグループの管理を持つグループは管理対象から外れる |
| Security Automation | 使えなくなる |
| 1Password CLIでの人の管理 | 2.36.0-beta.02以降でだけ使える |
| SCIM Bridge | このアカウントでは今後使えない |
参加の確認が即時になるのは、本人が招待を受け入れる操作で自分を証明するためです。SCIM Bridgeが一定の間隔でまとめて確認する方式より、安全性も上がります。
移行の前にそろえること
移行を始める前に、次の3つの観点で条件を確かめます。
1Password側の条件
作業する人は、所有者か管理者グループに属している必要があります。今いる全員のメールアドレスのドメインが、許可ドメインに入っていることを確かめてください。gmail.comのような公開ドメインは登録できないので、個人のアドレスで参加している人がいれば先に変更してもらいます。
IDプロバイダー側の条件
IDプロバイダーでは、アプリの設定を変えられる管理者の役割が要ります。Google Workspaceは条件が多く、Googleのサービスアカウントの作成と委任、課金を有効にしたGoogle Cloudのプロジェクト、同期するグループの作成が先に必要です。準備はGoogle Workspaceとの統合に従ってください。グループの一覧はセットアップの途中で更新されません。
運用への影響
Security Automationを使っている場合は、移行すると止まります。代わりの仕組みを決めてから進めてください。アカウントの復旧などを持つグループのメンバーをIDプロバイダーで管理していた場合は、移行後は1Password側で手動で出し入れします。誰がその作業を担うかを決めておきます。Ripplingは移行の対象外なので、SCIM Bridgeを使い続けます。
【注意】 移行した後は、SCIM Bridgeに戻せません。切り替えを始める前に、上の条件を全て確かめてください。
1Password側で切り替える
1Passwordの画面とIDプロバイダーの画面を、別のタブで並べて作業します。
- 1Password.comにサインインし、サイドバーの
統合を選んで、プロビジョニングの詳細を開きます。 - ホスト型プロビジョニングへの切り替えを選び、セットアップを始めます。
- 表示されたSCIMのURLとベアラートークンを、1Passwordのアイテムとして保存します。
- この画面を開いたまま、IDプロバイダーの作業に移ります。
Google Workspaceの場合は流れが違います。Google Workspaceの統合の画面でホスト型プロビジョニングへの切り替えを選び、アカウント名を入れて確定します。続けて、Googleのサービスアカウントのキー（JSONのファイル）と、Google Workspaceの管理者のメールアドレスを登録します。表示されたセットアップのスクリプトをCloud Shellで実行し、同期するグループを選んで完了させます。選んだグループに入っていない人は、1Password側で一時停止されます。一時停止の対象は、完了させる前に確認の画面で表示されます。
IDプロバイダー側の接続情報を差し替える
Google Workspace以外の4つは、IDプロバイダーのアプリの2つの欄を書き換えるだけです。URLの欄には、1Passwordのサインインアドレスではなく、控えたSCIMのURLを入れます。末尾にスラッシュを付けないでください。
| IDプロバイダー | 開く場所 | URLの欄 | トークンの欄 | 最後の操作 |
|---|---|---|---|---|
| Microsoft Entra ID | Enterprise applicationsの1PasswordのアプリのProvisioning、Admin Credentials | Tenant URL | Secret token | Test Connectionの後にSave |
| Okta | 1PasswordのアプリのProvisioningタブのIntegration、Edit | Base URL | API Token | Test API Credentialsの後にSave |
| JumpCloud | SSO Applicationsの1PasswordのアプリのConfiguration Settings | Base URL | Token key | Update |
| OneLogin | 1PasswordのアプリのConfiguration | SCIM Base URL | SCIM Bearer Token | Save |
保存したら1Passwordのタブに戻り、接続情報を1Passwordに保存して作業を完了させます。
Oktaは、続けて表示名の属性を対応付けます。displayNameの属性を追加しないと、1Passwordの表示名がOktaから更新されません。手順はOktaとの統合の属性の節と同じです。
SCIM Bridgeを撤去する
移行が済んだら、SCIM Bridgeと、それを動かしていた基盤を片付けます。残しておくと費用がかかり続け、使われない入り口が外に開いたままになります。
基盤とネットワーク
SCIM Bridgeのアプリやコンテナ、専用に作ったクラスターやリソースグループを削除します。Google Cloudで静的なIPアドレスに切り替えていた場合は、アドレスも解放します。使わなくなったDNSレコードは、他人に名前を乗っ取られる原因になるので消してください。
保管しているクレデンシャル
SCIM Bridgeのscimsessionファイルとベアラートークンのアイテムが、1Passwordに残っています。新しいSCIMのURLとベアラートークンと取り違えないよう、アイテムの名前で区別したうえで、撤去が済んだら削除します。
周辺の設定
SCIM Bridgeのために加えた設定も外します。1Passwordのファイアウォールで送信元のアドレスを許可するルール、Checklyのための受信の許可、社内の監視ツールの登録が当たります。