IDプロバイダーと1Passwordをつなぐ統合は2種類あります。人とグループを管理するプロビジョニングと、IDプロバイダーでサインインさせるUnlock with SSOです。2つは別の仕組みで、対応しているIDプロバイダーの範囲も違います。同じIDプロバイダーで両方を使えるとは限らず、両方を使う場合もIDプロバイダー側にアプリを2つ作ります。このページでは、2つの統合の違い、IDプロバイダーごとの対応状況、設定の方式の違い、一覧にないIDプロバイダーを使っている場合の確かめ方を説明します。どの方式を選ぶかは手動、自動プロビジョニング、SCIM Bridgeの比較で扱います。
2つの統合は別のもの
| 観点 | プロビジョニング | Unlock with SSO |
|---|---|---|
| 目的 | 人の追加と一時停止、グループの同期 | サインインとロックの解除 |
| 使う仕組み | SCIM | OpenID Connect（OIDC） |
| 1Password側の設定場所 | サイドバーの統合 | サイドバーのポリシーのシングルサインオン（SSO） |
| IDプロバイダー側のアプリ | プロビジョニング用に1つ | サインイン用に1つ |
どちらも、1つのアカウントに接続できるIDプロバイダーは1つです。プロビジョニングだけ、SSOだけ、という使い方もできます。
対応状況の一覧
| IDプロバイダー | プロビジョニング | Unlock with SSO |
|---|---|---|
| Microsoft Entra ID | 自動プロビジョニング | 対応（専用の手順） |
| Okta | 自動プロビジョニング | 対応（専用の手順） |
| JumpCloud | 自動プロビジョニング | 対応（専用の手順） |
| OneLogin | 自動プロビジョニング | 対応（汎用のOIDCの手順） |
| Google Workspace | 自動プロビジョニング | 対応（専用の手順） |
| Rippling | SCIM Bridge（Rippling側でのホストも可） | 専用の手順なし |
| Auth0 | 方式なし | 対応（専用の手順） |
| Duo | 方式なし | 対応（汎用のOIDCの手順） |
| Ping Identity | 方式なし | 対応（汎用のOIDCの手順） |
| その他のOIDC準拠のIDプロバイダー | 方式なし | 汎用のOIDCの手順で設定できる場合がある |
プロビジョニングの「方式なし」は、IDプロバイダーと直接つなぐ方法が用意されていないという意味です。この場合、人の管理は手動で行います。
SCIM Bridgeは将来廃止される予定です。Entra ID、Okta、JumpCloud、OneLogin、Google Workspaceは、SCIM Bridgeではなく自動プロビジョニングで接続します。SCIM Bridgeが必要なのはRipplingだけです。
設定の方式の違い
Unlock with SSOは、IDプロバイダーによって設定のしかたが3通りに分かれます。
Microsoft Entra IDの場合
Entra IDだけは、機密クライアントとしてアプリを登録します。条件付きアクセスポリシーを適用できるのはこのためです。オンプレミスのADFSを使っている組織は、ADFSを直接つなぐことはできず、Entra ID経由で接続します。手順はMicrosoft Entra IDでの設定で扱います。
専用の手順がある公開クライアントの場合
Okta、JumpCloud、Google Workspace、Auth0は、公開クライアントとしてアプリを登録します。認可コードフローとPKCEを使う形です。IDプロバイダーごとに入力する値と画面が違うため、1Password側でIDプロバイダーを選んでから進めます。OktaはOktaでの設定、ほかはその他のIDプロバイダーでの設定で扱います。
汎用のOIDCの手順で設定する場合
OneLogin、Duo、Ping Identityと、一覧にないIDプロバイダーは、汎用の手順で設定します。IDプロバイダー側でOIDCのアプリを作り、1Password側で表示されるリダイレクトURIを登録します。sub、name、emailの3つのクレームを返す必要があり、emailは1Passwordに登録したメールアドレスと一致しなければなりません。
一覧にないIDプロバイダーを使っている場合
国内のIDプロバイダーを含め、一覧にない製品を使っている場合は、次の3点をIDプロバイダーの提供元に確かめます。
- OpenID Connectに準拠していること
- 認可コードフローとPKCEを使う公開クライアントとしてアプリを登録できること
sub、name、emailのクレームを返せること。openid、email、profileのスコープを解釈できること
3点とも満たせば、Unlock with SSOを使える見込みがあります。SAMLだけに対応している製品は使えません。プロビジョニングは、一覧の6つ以外のIDプロバイダーでは使えないため、手動で管理します。
両方を使うときに合わせること
プロビジョニングとUnlock with SSOを同じIDプロバイダーで使う場合は、2つのアプリの間でメールアドレスの属性をそろえます。プロビジョニングで1Passwordに送るアドレスと、OIDCのemailクレームで返すアドレスが違うと、SSOでサインインできません。
プロビジョニングで取り込んだグループは、SSOを使う人の範囲の指定にも使えます。特定のグループだけにSSOを使わせる場合、新しく参加する人は参加する前にそのグループに入っている必要があります。これを実現できるのはプロビジョニングだけです。
ゲストは、SSOを使う範囲に含めるかどうかを選べます。社外のゲストは会社のIDプロバイダーにアカウントを持たないことが多いので、範囲から外すのが一般的です。範囲の決め方は導入前の確認とロールアウト設計で扱います。