SSOとSCIMの設定

SafeBaseの管理用の画面には、組織のIDプロバイダーを使ったシングルサインオン（SSO）でサインインできます。さらにSCIMを使うと、組織メンバーの追加や停止をIDプロバイダーに合わせて自動で行えます。このページでは、SAMLによるSSOの設定、全員にSSOを求める設定、サインインの方式の違いで重複したメンバーの整理、SCIMの設定を説明します。

SAMLによるSSOの仕組み

SafeBaseは、SAML 2.0とジャストインタイム（JIT）のプロビジョニングに対応しています。SSOをつなぐと、IDプロバイダーでSafeBaseのアプリケーションを割り当てられた人は、最初にサインインしたときにTrust Centerにアクセスできるようになります。組織メンバーの登録は、最初のサインインで自動で作られます。

項目	内容
使えるプラン	SAMLによるSSOは、SafeBaseの全てのプランで使える
対応するIDプロバイダー	SAML 2.0に対応したもの。Okta、Microsoft Entra ID、Google Workspace、OneLogin、JumpCloud、AD FS、Keycloak、PingFederateなど
社外の閲覧者への影響	ない。SSOは組織メンバーのためのもので、アカウントメンバーは引き続きアクセス申請とマジックリンクでアクセスする
SCIMとの関係	SSOをつないでも、ディレクトリーの同期（SCIMによるプロビジョニング）は有効にならない。SCIMは別の機能

【注意】 SafeBaseのアカウントをDrataで管理している場合、そのアカウントの認証はSafeBaseではなくDrataで管理されます。この場合は、SafeBaseのサポートに相談してください。

設定の前に準備すること

SSOの設定は、SafeBaseの管理者が設定用のリンクを作り、IDプロバイダーの管理者がそのリンクから開く設定の手引き（アシスタント）で接続を完成させる流れで進めます。2人が別の人であることが多いため、役割を確かめておきます。

担当	必要な権限	行うこと
SafeBaseの管理者	Adminのロール、またはUser Management & Authenticationの編集の権限を持つカスタムのロール	設定用のリンクを作り、後で強制の設定をオンにする
IDプロバイダーの管理者	IDプロバイダー（Okta、Entra ID、Google Workspaceなど）でアプリケーションを作る権限	設定の手引きを完了し、接続を試す

設定用のリンクは、開いてから5時間で期限が切れます。担当が2人に分かれる場合は、先に作業の日時を決めてから、リンクを作ります。次のものも用意しておきます。

用意するもの	内容
IDプロバイダーの管理者のアクセス	アプリケーションを作り、利用者を割り当てるため
IDプロバイダーのSAMLの情報	サインインのURLとX.509の署名用の証明書。設定の手引きで直接求められるため、メタデータのファイルかメタデータのURLを開いておく
まとまった時間	IDプロバイダーの管理者が中断せずに作業できる時間。多くの接続は20〜40分で終わる
新しいメンバーの既定のロールの方針	SSOで初めてサインインした全員に、Default Role for New Membersのロールが付く。ヘルプセンターでは、試験の間はAdminにしておき、その後に下げる進め方を挙げている
別のブラウザーかプライベートウィンドウ	今の管理者のセッションを保ったまま、SSOでのサインインを試すため

【注意】 接続を作り、試してうまくいくまでは、Require SSO Loginをオンにしないでください。接続が動く前にSSOを強制すると、チームがSafeBaseにサインインできなくなることがあります。

SafeBaseで設定を始める

1. Adminのロールの人がSafeBaseにサインインし、Settings → User Management & Authenticationを開きます。
2. Securityのセクションで、自動で作られたConnection ID（yourcompany-ssoのような形）を確かめ、コピーします。IDプロバイダーによっては、アプリケーションの設定でこの値を求められます。
3. Single Sign-Onの横の状態を確かめます。まだ設定していない場合はNot startedと表示されます。
4. Configure SSOを選びます。2つの期限を説明する確認の画面が表示されるため、内容を読んでから確定します。
5. Initiate setupを選びます。設定の手引きがブラウザーの新しいタブで開き、状態がSetup in progressに変わって、残り時間が表示されます。
6. IDプロバイダーの管理者が別の人の場合は、新しいタブのアドレスを送ります。

【注意】 設定の手引きのリンクは、パスワードと同じように扱ってください。リンクを持っている人は、誰でも接続を設定できます。

設定用のリンクには、次の2つの期限があります。

期限	始まり	長さ
始めるまでの期限	Configure SSOを選んだとき	5日
終えるまでの期限	リンクを初めて開いたとき	5時間

5時間の期限は延ばせません。期限が切れると、そのリンクで行った作業は取り戻せないため、SecurityのセクションでRestart setupを選び、新しいリンクを作ります。IDプロバイダー側で設定した内容は失われません。

Securityのセクションには、設定の状況に応じて次のボタンが表示されます。

ボタン	表示される場面	働き
Configure SSO	設定を始めていない	設定用のリンクを作る
Initiate setup	リンクはあるが、まだ開いていない	設定の手引きを開き、5時間の期限を始める
Continue setup	リンクを開いた後で、まだ有効	設定の手引きを、中断したところから開き直す
Restart setup	リンクの期限が切れた	新しいリンクを作る
Edit setup	接続が既にある	設定の手引きを開き直し、既存の接続を変える
Revoke setup	リンクを開いた後で、まだ有効	リンクを直ちに無効にする

Revoke setupでリンクを無効にした後は、数秒待ってから新しい設定を始めます。SafeBaseが以前のリンクの後始末を先に終えるためです。

設定の手引きを完了する

設定の手引きは、SafeBaseの外で進めます。どのIDプロバイダーでも、同じSAMLの手順と画面で進みます。

1. 設定の手引きに表示される、接続用のサインインのURL（ACS URL）とオーディエンスURIをコピーします。
2. IDプロバイダーでSAMLのアプリケーションを作り、手順1の2つの値を入れます。
3. IDプロバイダーのサインインのURLと、X.509の署名用の証明書を、設定の手引きに入れます。
4. IDプロバイダーが送る属性（クレーム）を、SafeBaseが求める項目に対応付けます（次の表）。
5. SafeBaseを使う人とグループに、アプリケーションを割り当てます。最初は少人数の試験用のグループから始めます。
6. 接続を試します。設定の手引きが新しいタブで試験のサインインを開きます。これが成功するまで、先に進まないでください。
7. （任意）プロビジョニングを設定します。アカウントでSCIMによるプロビジョニングが有効な場合だけ表示されます。
8. （任意）ドメインを確認します。アカウントの設定によって表示されます。

属性の対応付けは次の通りです。対応付けの誤りは、認証はできても、メンバーの情報が欠ける接続になる最も多い原因です。

SafeBaseの項目	IDプロバイダーの主な属性	必須
email	email、mail、ユーザープリンシパル名	必須
firstName	given_name、firstName	推奨
lastName	family_name、lastName	推奨
ID	利用者を一意に識別する、変わらない値	必須

名前の属性がなくてもサインインはできますが、対応付けないと、メンバーの名と姓が空欄のままSafeBaseに表示されます。

IDプロバイダーごとの属性

設定の手引きはIDプロバイダーを問わない作りのため、IDプロバイダーの画面での具体的な作業は、ヘルプセンターの「Integration - Single Sign-On (SSO)」のIDプロバイダーごとの節に従います。属性の対応付けは次の通りです。

IDプロバイダー	属性の対応付け	注意する点
Okta	firstNameにuser.firstName、lastNameにuser.lastName、emailにuser.email、idにuser.login	利用者がTrust Centerにアクセスする前に、Oktaでアプリケーションが正しく割り当てられているかを確かめる
OneLogin	First nameをfirstName、Last nameをlastName、Emailをemail、Usernameをidに対応付ける	利用者がTrust Centerにアクセスする前に、OneLoginでアプリケーションが正しく割り当てられているかを確かめる
Google Workspace	First nameをfirstName、Last nameをlastName、Primary emailをuser_idとemailに対応付ける	「Error: app_not_enabled_for_user」が出る場合は、利用者のアクセスの有効化が既定でオフになっていることを確かめる。設定の反映に時間がかかり、「403: Not a SaaS application」などのエラーが出ることがあるが、1時間以上待つと解消することが多い
Microsoft Entra ID	一意の利用者の識別子（Name ID）にuser.userprincipalname、firstNameにuser.givenname、lastNameにuser.surname、emailにuser.mail、idにuser.userprincipalname	クレームの名前は大文字と小文字を区別する。クレームの名前空間に最初から入っているURIは削除する
JumpCloud	firstNameにfirstname、lastNameにlastname、emailにemail、idにemail	―

SafeBaseへの要求に署名が必要な場合は、IDプロバイダーで署名を有効にし、ヘルプセンターの記事に添付されたSafeBaseの証明書を使います。

設定の手引きを使わずに、SafeBaseに接続の設定を任せることもできます。この場合は、Trust Centerのサポートのチャットで新しいSSOの設定を依頼し、使っているIDプロバイダーと、IDプロバイダーのメタデータのURLかmetadata.xmlのファイルを伝えます。

接続を作った後に行うこと

Settings → User Management & Authenticationに戻ると、SSOの状態がConnectedになっています。表示の更新に少し時間がかかることがあるため、変わっていない場合はページを再読み込みします。

1. 自分でサインインを試します。今の管理者のセッションを保つため、プライベートウィンドウか別のブラウザーで、IDプロバイダーを通してSafeBaseにサインインします。メンバーの登録で、名前、メールアドレス、ロールが正しいかを確かめます。
2. 新しいメンバーの既定のロールを確かめます。新しい人は、SSOで初めてサインインしたときにSafeBaseに登録され、Default Role for New Membersのロールが付きます。広いグループにアクセスを開く前に、適切なロールにしておきます。既定のロールの考え方は、組織メンバーとロールで説明しています。
3. SSOを強制します。SecurityのセクションのRequire SSO Loginをオンにすると、SafeBaseのメンバーはIDプロバイダーを通してサインインする必要があります。

【注意】 Require SSO Loginは、自分がSSOでサインインしている必要があります。自分のSAMLの接続でサインインするまで切り替えは無効のままで、ツールチップに「Log in with your SAML account to enforce」と表示されます。いったんサインアウトし、SSOでサインインし直してから、このページに戻ってオンにします。

強制の設定をオンにすると、次のことが変わります。

変わること	内容
既存のメンバー	削除されない。パスワードやGoogleでサインインしていた人は、メンバーとして残るがサインインできなくなる。アクセスが不要な人は、User Managementの一覧から削除する
アプリ内からの招待	使えなくなる。IDプロバイダーでSafeBaseのアプリケーションを割り当てて人を加える
ドメインによる自動の参加	使えなくなる。メンバーはIDプロバイダーに基づいて加わる
Googleでのサインインの強制	解除される。GoogleとSAMLの両方を強制することはできない

接続を変える

証明書の更新、属性の対応付けの修正、アプリケーションの設定の変更は、SecurityのセクションでEdit setupを選び、既存の接続に対して設定の手引きを開き直して行います。リンクを開いた後は、同じように5時間の期限があります。

組織のメールアドレスのドメインは、接続を最初に作ったときに接続に結び付けられ、そのドメインの人をIDプロバイダーに案内するのに使われます。SSOをつないだ後にメールアドレスのドメインを追加したり変えたりする場合は、SafeBaseのサポートに依頼します。既存の接続には自動では反映されません。

SSOがうまくいかないとき

起きていること	対応
最初のサインインの後、名と姓が空欄	属性の対応付けが不足している。IDプロバイダーで対応付けを直し、サインアウトしてサインインし直す。ブラウザーのSafeBaseのキャッシュとサイトのデータを消すのも効く
設定用のリンクの期限が切れた	Restart setupで新しいリンクを作る。IDプロバイダーで設定した内容は失われない
状態がSetup in progressのまま変わらない	設定の手引きが終わっていない。Continue setupを選び、SSOの試験を含む残りの手順を終える
設定のボタンを選んでも何も起きない	ブラウザーが新しいタブをブロックしている。SafeBaseのポップアップを許可して、もう一度試す
Require SSO Loginをオンにできない	接続がまだないか、今SSOでサインインしていない。IDプロバイダーを通してサインインし直す
メンバーがIDプロバイダーに案内されない	メールアドレスのドメインが接続に結び付けられていない可能性がある。SafeBaseのサポートにドメインを確かめてもらう
証明書や署名のエラーでサインインできない	IDプロバイダーの署名用の証明書が変わったか、期限が切れている。Edit setupで更新する

次の場合は、設定の手引きではなく、SafeBaseのサポートに相談します。

• IDプロバイダーを設定の手引きで設定できない場合
• SafeBaseのアカウントをDrataで管理している場合
• 接続に結び付けたメールアドレスのドメインを追加、変更したい場合
• ディレクトリーの同期（SCIMによるプロビジョニング）を使いたい場合

サインインの方式の違いで重複したメンバーを整理する

組織メンバーが最初にユーザー名とパスワードでサインインし、後からGoogleのSSOやSAMLのSSOを使うと、サインインの方式ごとに別々の組織メンバーの登録が残ります。SafeBaseは、監査の記録と利用者ごとの履歴を保つため、サインインの方式ごとに別の利用者として扱うためです。SAMLのSSOを有効にすると、利用者がサインインの方式を切り替えたときに、このような重複が起きることがあります。

重複した登録は、次の手順で整理します。

1. 重複した登録のうち、どれがSAMLのSSO（または使い続けるサインインの方式）に結び付いていて、どれがそうでないかを確かめます。
2. SAMLのSSOに結び付いていない登録が不要であれば、混乱を防ぐため、User Managementの一覧で停止します。停止した登録は無効になりますが、記録のためにシステムに残ります。

今後の重複を防ぐには、サインインの方式を1つにそろえ、全員にSAMLのSSOでの認証を求めます。この設定は、Settings → SecurityでRequire SAML authentication for all membersをオンにして行います。GoogleのSSOなど、ほかのサインインの方式を許さないようにすると、今後は重複が起きないようにできます。

SCIMでメンバーの管理を自動にする

SCIMを使うと、組織のIDプロバイダーを使って、Trust Centerへの利用者の登録と登録の解除（プロビジョニングとデプロビジョニング）を自動で行えます。SCIMは、AdvancedとEnterpriseの全てのプランに含まれます。契約のプランで使えるかは、正規販売代理店（デジタルアクセルズ）にご相談ください。

前提

• SafeBaseの管理者で、組織のIDプロバイダーで必要な権限を持っていること
• SAMLを設定済みで、SafeBaseのSettingsでRequire SAML Authentication for all membersをオンにして、SAMLを強制していること。SCIMのプロビジョニングの項目は、ログインの方式としてSAMLを強制した後でなければ使えるようになりません

設定する

1. 組織メンバーの一覧の右上のConfigure Directory Sync (SCIM)を選びます。
2. ディレクトリーの同期の画面で、Go To Directory Syncを選びます。SafeBaseが使う外部のSCIMのサービス（WorkOS）に移動します。
3. IDプロバイダーを選びます。
4. WorkOSが、IDプロバイダーごとの具体的な手順を示すので、それに従います。ヘルプの記事の画像の例では、WorkOSが示したSCIMのベースURLとOAuthのベアラートークンを入れています。

組織メンバーの一覧。右上のConfigure Directory Sync (SCIM)から、ディレクトリーの同期を設定する

【運用のポイント】 SAMLのアプリケーションは、SSOの設定で既に作っています。WorkOSでは既存のアプリケーションを使うか新しく作るかを選べますが、SafeBaseは既存のアプリケーションにSCIMの情報を加える方法を勧めています。新しいアプリケーションから同じ利用者が重複して同期されるのを防げます。

設定の中で、次のような動きを選べます。

• IDプロバイダーの権限に基づいて、新しい利用者をSafeBaseに取り込む
• 名前やメールアドレスの変更など、利用者の変更を取り込む
• IDプロバイダーで停止された利用者や、対象のグループから外された利用者を、SafeBaseでも自動で停止する

ディレクトリーの同期を有効にするにはSAMLが必要で、Require SSO Loginはオンのまま固定されます。メンバーの管理は、全てIDプロバイダーで行うことになります。

SCIMとロール

設定が終わると、利用者がSafeBaseに登録されます。SCIMを使う前にジャストインタイムのプロビジョニングで作られていた利用者は、改めて登録されません。

SCIMでグループを送る（push groups）設定にすると、グループがGroupsタブに表示され、SafeBaseの管理者はグループごとにロールを対応付けられます。どのグループにも属さない利用者には、既定のロールが付きます。

Groupsタブ。IDプロバイダーから送られたグループごとに、SafeBaseのロールを対応付ける

利用者ごとの権限は、組織メンバーの一覧のロールの選択欄でも上書きできます。SafeBaseは、グループに対応付けたロールとロールの選択欄のロールのうち、高い方の権限をその利用者に付けます。

グループを送る場合、SafeBaseで変えられるのは、グループに対応付けるロールだけです。グループの内容とメンバーの編集、グループの作成と削除は、SCIMの提供元（IDプロバイダー）で行い、SafeBaseはその変更を同期します。

SCIMがうまくいかないとき

起きていること	対応
特定の利用者がSafeBaseに同期されない	IDプロバイダーで、その利用者にSafeBaseのSCIMのアプリケーションが割り当てられているかを確かめる
SCIMの接続を作った後	接続を作った管理者が、SafeBaseに送るグループのいずれかに入っているかを確かめる
SCIMの設定の項目が表示されない	SAMLの認証を設定しただけでなく、強制まで済ませているかを確かめる
強制のエラーが出る	画面の案内に従い、「Log in with your SAML provider」のボタンからサインインして、強制を完了する

ディレクトリーの接続を外すには、組織メンバーの一覧の右上のConfigure Directory Sync (SCIM)を選び、Disconnect directoryを選びます。接続を外すと、有効な組織メンバーは、以前のサインインの方式でサインインできるようになります。