configuring-sso-and-scim

SSO と SCIM の設定

CockroachDB のシングルサインオン（SSO）と SCIM 2.0 プロビジョニングを、次の 4 つのレイヤーで設定します。

1. Cloud Console SSO — CockroachDB Cloud Web コンソール用の SAML または OIDC
2. DB Console SSO — DB Console Web UI 用の OIDC（Advanced／Enterprise のみ）
3. SQL／クラスター SSO — SQL クライアント接続用の JWT ベース認証または LDAP／AD 認証
4. SCIM 2.0 — Cloud Console でのユーザープロビジョニングの自動化

前提条件

• Console SSO／SCIM: Organization Admin 権限と ccloud CLI
• DB Console／SQL SSO: クラスター管理者ロールと Advanced または Enterprise プラン（DB Console SSO は Standard／Basic では利用できません）
• LDAP／AD: セルフホスト環境のみ（CockroachDB Cloud では利用できません）
• SCIM 2.0: Enterprise プランが必要です

設定の決定

先に進む前に、ユーザーに必要なレイヤーを確認します。以下のどれに該当するか尋ね、該当する Part のみを進めてください。

決定 1 — Cloud Console SSO:

• SAML: SAML インフラストラクチャがすでにあるエンタープライズ IdP（Okta、Azure AD、PingOne）に最適です
• OIDC: 設定がより簡単で、Google Workspace や最新の IdP をネイティブにサポートします
• スキップ: 不要です

決定 2 — DB Console SSO:

• 有効化（OIDC）: DB Console Web UI 用の SSO です。Advanced または Enterprise プランが必要です。Standard または Basic では利用できません
• スキップ: 不要、またはプランが対応していません

決定 3 — SQL／クラスター SSO の方式:

• JWT ベース: SQL クライアント接続に JWT トークンを使用するクラウドネイティブな方式です。CockroachDB Cloud とセルフホストクラスターの両方で動作します
• LDAP／AD: Active Directory または OpenLDAP に対する直接のディレクトリ認証です。セルフホスト環境のみ（CockroachDB Cloud では利用できません）
• スキップ: 不要です

決定 4 — SCIM 2.0 プロビジョニング:

• 有効化: IdP と Cloud Console 間でユーザーのライフサイクル（作成／更新／無効化）を自動化します。Enterprise プランが必要です
• スキップ: Cloud Console ユーザーを手動で管理します

手順

Part 1: Cloud Console SSO

Cloud Console SSO を使用すると、CockroachDB Cloud Web コンソールで SAML または OIDC 認証を利用できます。

1.1 現在の SSO 設定を確認する

Cloud Console UI の［Organization Settings > Authentication］で SSO のステータスを確認します。

1.2a SAML SSO を設定する

決定 1 でユーザーが SAML を選択した場合は、このセクションに従ってください。

1. Cloud Console の［Organization Settings > Authentication］に移動します
2. SSO プロバイダーの種類として SAML を選択します
3. SAML 接続を設定します。
   • IdP メタデータ URL を入力するか、メタデータ XML をアップロードします
   • CockroachDB Cloud の ACS URL と Entity ID をコピーして、IdP に設定します
   • IdP 属性を CockroachDB Cloud のユーザーフィールド（email、name）にマッピングします
4. IdP で SAML 2.0 アプリケーションを作成します。
   • Single sign-on URL に CockroachDB Cloud の ACS URL を設定します
   • Audience URI (SP Entity ID) に CockroachDB Cloud の Entity ID を設定します
   • Name ID format を Email Address に設定します
   • 属性をマッピングします：email、firstName、lastName
5. IdP でユーザーまたはグループを SAML アプリケーションに割り当てます

IdP 固有の SAML 手順（Okta、Azure AD）については、設定手順のリファレンスを参照してください。

1.2b OIDC SSO を設定する

Decision 1 でユーザーが OIDC を選択した場合は、このセクションの手順に従います。

1. Cloud Console で Organization Settings > Authentication に移動します
2. SSO プロバイダーの種類として OIDC を選択します
3. OIDC 接続を設定します：
   • IdP の OIDC ディスカバリー URL（例：https://accounts.google.com/.well-known/openid-configuration）を入力します
   • IdP の Client ID と Client Secret を入力します
   • IdP のリダイレクト URI が CockroachDB Cloud を指すように設定します
4. IdP で OIDC/OAuth 2.0 アプリケーションを作成します：
   • Sign-in redirect URI に CockroachDB Cloud のリダイレクト URI を設定します
   • スコープとして openid、profile、email を許可します
5. IdP でユーザーまたはグループを OIDC アプリケーションに割り当てます

IdP ごとの OIDC 手順（Okta、Azure AD、Google Workspace）については、設定手順のリファレンスを参照してください。

1.3 SSO ログインをテストする

1. 新しいブラウザーセッション（またはシークレットウィンドウ）を開きます
2. CockroachDB Cloud Console のログインページに移動します
3. Sign in with SSO を選択します
4. IdP にリダイレクトされることを確認し、認証後、Cloud Console に戻ることを確認します

1.4 SSO を必須にする（パスワードログインを無効にする）

SSO が機能することを確認したら、次の手順に従います：

1. Organization Settings > Authentication に移動します
2. Require SSO を有効にして、パスワードベースのログインを無効にします
3. 緊急時用の管理者アカウントが存在することを確認します（「安全に関する考慮事項」を参照）

Part 2：DB Console SSO（OIDC）

この設定で SSO が有効になるのは DB Console のウェブ UI のみであり、SQL クライアント接続には適用されません。 SQL クライアントの SSO は、Part 3（JWT）または Part 4（LDAP/AD）で別途設定します。

前提条件： Advanced または Enterprise プランが必要です。DB Console SSO は Standard または Basic プランでは利用できません。

DB Console SSO では、OIDC を使用して CockroachDB DB Console のウェブインターフェースにユーザーを認証します。

2.1 現在の DB Console SSO 設定を確認する

SHOW CLUSTER SETTING server.oidc_authentication.enabled;
SHOW CLUSTER SETTING server.oidc_authentication.provider_url;
SHOW CLUSTER SETTING server.oidc_authentication.client_id;

2.2 DB Console SSO を設定する

-- Enable OIDC authentication for the DB Console
SET CLUSTER SETTING server.oidc_authentication.enabled = true;

-- Set the OIDC provider URL (your IdP's discovery endpoint)
SET CLUSTER SETTING server.oidc_authentication.provider_url = 'https://your-idp.example.com';

-- Set the client ID registered in your IdP
SET CLUSTER SETTING server.oidc_authentication.client_id = '<client-id>';

-- Set the client secret
SET CLUSTER SETTING server.oidc_authentication.client_secret = '<client-secret>';

-- Configure the claim field used for username mapping
SET CLUSTER SETTING server.oidc_authentication.claim_json_key = 'email';

-- Configure the principal regex (extract username from claim)
SET CLUSTER SETTING server.oidc_authentication.principal_regex = '^([^@]+)';

IdP ごとの DB Console SSO の設定手順（Okta、Azure AD）については、設定手順のリファレンスを参照してください。

2.3 DB Console SSO をテストする

1. ブラウザーで DB Console の URL を開きます
2. Log in with OIDC をクリックします
3. IdP で認証します
4. DB Console にログインできたことを確認します

Part 3：SQL/Cluster SSO（JWT）

SQL/Cluster SSO では、IdP の JWT トークンを使用して SQL クライアント接続を認証します。これは DB Console SSO（Part 2）とは別のもので、ウェブ UI ではなく cockroach sql とアプリケーション接続を認証します。

3.1 現在の JWT SSO 設定を確認する

SHOW CLUSTER SETTING server.jwt_authentication.enabled;
SHOW CLUSTER SETTING server.jwt_authentication.issuers.configuration;
SHOW CLUSTER SETTING server.jwt_authentication.jwks_auto_fetch.enabled;

3.2 JWT 認証を設定する

-- Enable JWT authentication for SQL connections
SET CLUSTER SETTING server.jwt_authentication.enabled = true;

-- Configure the JWT issuer(s)
-- Format: JSON object with issuer URL and audience
SET CLUSTER SETTING server.jwt_authentication.issuers.configuration = '{
  "issuers": [
    {
      "issuer": "https://your-idp.example.com",
      "audience": "<client-id>"
    }
  ]
}';

-- Enable automatic JWKS fetching (recommended)
SET CLUSTER SETTING server.jwt_authentication.jwks_auto_fetch.enabled = true;

-- Configure the claim used for SQL username mapping
SET CLUSTER SETTING server.jwt_authentication.claim = 'email';

IdP ごとの JWT 設定（Okta、Azure AD、Google）については、設定手順のリファレンスを参照してください。

3.3 ID マッピングを設定する

IdP の ID（例：メールアドレス）を SQL ユーザー名にマッピングします：

-- Map [email protected] -> user (strip domain)
SET CLUSTER SETTING server.identity_map.configuration = '
crdb /^(.*)@example\.com$ \1
';

3.4 ユーザーの自動プロビジョニングを有効にする（任意）

JWT で初めて認証した際に SQL ユーザーを自動プロビジョニングします：

SET CLUSTER SETTING security.provisioning.jwt.enabled = true;

有効にすると、認証済みの JWT ユーザーにアカウントがまだない場合、SQL ユーザーが自動的に作成されます。

3.5 SQL/Cluster SSO をテストする

# Obtain a JWT token from your IdP (method varies by IdP)
# Then connect using the token as the password with JWT auth enabled
cockroach sql --url "postgresql://<username>@<cluster-host>:26257/defaultdb?sslmode=verify-full&options=--crdb:jwt_auth_enabled=true" --external-io-implicit-credentials

JWT トークンはパスワードとして渡されます。接続オプション --crdb:jwt_auth_enabled=true を指定すると、CockroachDB はパスワードを JWT トークンとして扱います。

-- Verify the connection
SELECT current_user();

Part 4：LDAP/AD 認証

LDAP/AD 認証では、LDAP ディレクトリ（Active Directory または OpenLDAP）に対して SQL 認証情報を直接検証します。セルフホスト環境のみで利用でき、CockroachDB Cloud では利用できません。

警告 — HBA は最初に一致したルールが適用されます： HBA ルールは上から順に評価されます。最初に一致したルールが使用されます。host all all all ldap ... のようなルールは、すべてのアドレスからのすべてのユーザーに一致するため、どのユーザーについてもパスワードへのフォールバックができなくなります。管理者アカウントがロックアウトされないよう、LDAP ルールは必ず特定のユーザーまたはロールに限定してください。

4.1 現在の HBA 設定を確認する

SHOW CLUSTER SETTING server.host_based_authentication.configuration;

4.2 HBA 経由で LDAP 認証を設定する

LDAP 認証は HBA（ホストベース認証）ルールで設定します。LDAP ルールは必ず特定のデータベースまたはユーザーに限定してください。host all all all ldap は決して使用しないでください。

-- Configure HBA for LDAP authentication scoped to specific users
-- The 'root' user and other admin users keep password auth
SET CLUSTER SETTING server.host_based_authentication.configuration = '
host all root all password
host all admin_user all password
host all all all ldap "ldapserver=ldap.example.com" "ldapport=389" "ldapbasedn=dc=example,dc=com" "ldapsearchattribute=uid" "ldapsearchfilter=(objectClass=inetOrgPerson)" "ldapbinddn=cn=readonly,dc=example,dc=com" "ldapbindpasswd=<bind-password>"
host all all all password
';

LDAP HBA の主なパラメーター：

• ldapserver — LDAP サーバーのホスト名
• ldapport — LDAP サーバーのポート（LDAP の場合は 389、LDAPS の場合は 636）
• ldapbasedn — ユーザー検索のベース DN
• ldapsearchattribute — SQL ユーザー名と照合する属性（例：OpenLDAP では uid、AD では sAMAccountName）
• ldapsearchfilter — **必須。**ユーザー検索を絞り込む LDAP フィルター（例：(objectClass=inetOrgPerson)）
• ldapbinddn — LDAP のバインド／検索に使用するサービスアカウントの DN
• ldapbindpasswd — バインド DN サービスアカウントのパスワード

**重要：**各 HBA オプションは "key=value" の形式で引用符で囲んでください（key=value 全体を一組の引用符で囲みます）。

Active Directory、OpenLDAP、グループマッピング、LDAPS の例については、設定手順のリファレンスを参照してください。

4.3 本番環境で LDAPS（TLS）を使用する

本番環境では、通信中の認証情報を暗号化するために、必ず LDAPS（ポート 636 の TLS 経由 LDAP）を使用してください。ldaptls=1 は使用しないでください。このオプションはサポートされていません。代わりにポート 636 を使用し、カスタム CA 証明書を設定してください。

-- Configure the LDAP CA certificate for TLS verification
SET CLUSTER SETTING server.ldap_authentication.domain.custom_ca = '-----BEGIN CERTIFICATE-----
<your-ldap-ca-certificate-pem>
-----END CERTIFICATE-----';

-- Set HBA to use LDAPS (port 636)
SET CLUSTER SETTING server.host_based_authentication.configuration = '
host all root all password
host all admin_user all password
host all all all ldap "ldapserver=ldap.example.com" "ldapport=636" "ldapbasedn=dc=example,dc=com" "ldapsearchattribute=uid" "ldapsearchfilter=(objectClass=inetOrgPerson)" "ldapbinddn=cn=readonly,dc=example,dc=com" "ldapbindpasswd=<bind-password>"
host all all all password
';

4.4 LDAP グループからロールへのマッピングを設定する

LDAP グループマッピングでは、LDAP／AD グループへの所属に基づいて CockroachDB SQL ロールを割り当てます。グループマッピングはクラスタ設定ではなく、HBA パラメーター ldapgrouplistfilter で設定します。

-- HBA with group-to-role mapping
SET CLUSTER SETTING server.host_based_authentication.configuration = '
host all root all password
host all admin_user all password
host all all all ldap "ldapserver=ad.corp.example.com" "ldapport=636" "ldapbasedn=ou=Users,dc=corp,dc=example,dc=com" "ldapsearchattribute=sAMAccountName" "ldapsearchfilter=(objectClass=user)" "ldapbinddn=cn=crdb-svc,ou=ServiceAccounts,dc=corp,dc=example,dc=com" "ldapbindpasswd=<service-account-password>" "ldapgrouplistfilter=(&(objectClass=group)(member={{.User.DN}}))"
host all all all password
';

LDAP グループの CN は SQL ロール名に直接マッピングされます。ロールは CockroachDB にあらかじめ作成しておく必要があります。

CREATE ROLE IF NOT EXISTS db_admins;
GRANT admin TO db_admins;

4.5 ユーザーの自動プロビジョニングを有効にする（任意）

ユーザーが初めて LDAP で認証するときに、SQL ユーザーを自動的にプロビジョニングします。

SET CLUSTER SETTING security.provisioning.ldap.enabled = true;

4.6 LDAP 認証をテストする

# Test with an LDAP user credential
cockroach sql --url "postgresql://<ldap-username>:<ldap-password>@<cluster-host>:26257/defaultdb?sslmode=verify-full"

-- Verify the user connected successfully
SELECT current_user();

-- If group mapping is enabled, verify role grants
SHOW GRANTS FOR <ldap-username>;

Part 5：Cloud Console での SCIM 2.0

ユーザーの自動プロビジョニングが必要ない場合、または Enterprise プランを利用していない場合は、このセクションをスキップしてください。

SCIM 2.0 を使うと、Cloud Console でユーザーのプロビジョニングとプロビジョニング解除を自動化し、ユーザーのライフサイクルを IdP と同期できます。

5.1 現在の SCIM 設定を確認する

Cloud Console UI（Organization Settings > Authentication > SCIM）で SCIM のステータスを確認します。現在、ccloud CLI では SCIM 設定コマンドは公開されていません。

5.2 SCIM エンドポイントを有効にする

1. Cloud Console で Organization Settings > Authentication > SCIM に移動します
2. SCIM 2.0 エンドポイントを有効にします
3. IdP の設定に使用する SCIM ベース URL と Bearer トークン をコピーします

5.3 SCIM 用に IdP を設定する

IdP（Okta、Azure AD など）で次の操作を行います。

1. 新しい SCIM プロビジョニング連携を追加します
2. 手順 5.2 の SCIM ベース URL を入力します
3. 認証用の Bearer トークンを入力します
4. プロビジョニングの操作を設定します。
   • ユーザーの作成 — 新しい IdP ユーザーが CockroachDB Cloud に作成されます
   • ユーザー属性の更新 — 名前とメールアドレスの変更が同期されます
   • ユーザーの無効化 — IdP から削除されたユーザーが CockroachDB Cloud で無効化されます
5. SCIM 連携にユーザーまたはグループを割り当てます

IdP ごとの SCIM 設定については、設定手順のリファレンスを参照してください。

5.4 SCIM プロビジョニングを確認する

1. IdP でテストユーザーを作成し、SCIM 連携に割り当てます
2. Cloud Console を確認します。数分以内にユーザーが表示されます
3. IdP の SCIM 割り当てからテストユーザーを削除します
4. Cloud Console でユーザーが無効化されていることを確認します

トラブルシューティング

SSO によるロックアウトからの復旧

SSO が強制されている状態で、IdP が利用できなくなったり、設定に問題が発生したりした場合：

1. **緊急用アカウントを使用する：**事前設定したパスワード認証の管理者アカウントでログインします
2. **SSO の強制を無効にする：**Organization Settings > Authentication に移動し、「Require SSO」を無効にします
3. **緊急用アカウントがない場合：**組織の SSO 強制を無効にするよう CockroachDB Cloud サポートに連絡します

**予防策：**SSO を強制する前に、必ず緊急用の管理者アカウントを作成してテストしてください。

JWT 認証エラー

「ERROR: JWT authentication: invalid token」

• server.jwt_authentication.issuers.configuration の JWT 発行者設定を確認します
• JWT トークンの有効期限が切れていないことを確認します
• server.jwt_authentication.jwks_auto_fetch.enabled が true であることを確認します
• トークンの内容を確認します：echo '<token>' | cut -d. -f2 | base64 -d | jq .
• トークンの aud（オーディエンス）クレームが、設定されたオーディエンスと一致することを確認します

「ERROR: JWT authentication: issuer not configured」

• トークン内の発行者 URL が server.jwt_authentication.issuers.configuration と一致していません
• 発行者 URL が完全に一致していることを再確認します（末尾のスラッシュも重要です）

DB コンソールの OIDC エラー

「OIDC: unable to match principal」

• server.oidc_authentication.principal_regex がトークンのクレーム値と一致していません
• 実際のクレーム値に対して正規表現をテストします：

SHOW CLUSTER SETTING server.oidc_authentication.principal_regex;
-- Common patterns:
-- Email -> username (strip domain): '^([^@]+)'
-- Full email as username: '^(.+)$'

複雑な正規表現が受け付けられない場合：

• CockroachDB は Go の regexp 構文を使用します（先読み／後読みは使用できません）
• 「Golang」フレーバーを選択して https://regex101.com/ でテストします

LDAP 認証エラー

「ERROR: LDAP authentication: unable to bind」

• ldapbinddn と ldapbindpasswd が正しいことを確認します
• バインド用サービスアカウントに、ユーザー検索ベースへの読み取りアクセス権があることを確認します
• 次のコマンドでテストします：ldapsearch -H ldap://ldap.example.com -D "cn=readonly,dc=example,dc=com" -W -b "dc=example,dc=com" "(uid=testuser)"

「ERROR: LDAP authentication: user not found」

• ldapbasedn にユーザーが属する OU が含まれていることを確認します
• ldapsearchattribute がログイン属性と一致していることを確認します（OpenLDAP では uid、AD では sAMAccountName）
• ldapsearchfilter が設定されていることを確認します — 設定されていないと、LDAP ユーザー検索は失敗します

LDAP ロックアウト — すべてのユーザーがブロックされる

• host all all all ldap ... のような範囲が広すぎる HBA ルールが最初にあり、LDAP サーバーに到達できない場合、または LDAP 設定が誤っている場合に発生します
• 修正： ldap ルールより前に、root と管理者ユーザー用の明示的な password ルールを設定します
• 復旧： クライアント証明書認証（HBA を迂回します）を使用して root として接続し、HBA 設定を修正します

LDAP サーバーに到達できない

• CockroachDB ノードから LDAP サーバーへのネットワーク接続を確認します
• LDAPS の場合は、server.ldap_authentication.domain.custom_ca を使用して CA 証明書が設定されていることを確認します
• ポート 389（LDAP）または 636（LDAPS）のファイアウォールルールを確認します

Azure AD / Entra ID 固有の問題

トークンのオーディエンスが一致しない：

• Azure AD トークンには aud クレームが含まれており、設定されたオーディエンスと一致する必要があります
• JWT SQL SSO の場合：server.jwt_authentication.issuers.configuration のオーディエンスが一致することを確認します
• DB コンソールの OIDC の場合：server.oidc_authentication.client_id が一致することを確認します

マルチテナントとシングルテナント：

• シングルテナントの場合、発行者として https://login.microsoftonline.com/<tenant-id>/v2.0 を使用します
• マルチテナントの場合、https://login.microsoftonline.com/common/v2.0 を使用します（追加の検証が必要です）

ldapsearchfilter の不足

ユーザーがディレクトリに存在するにもかかわらず、LDAP 認証で「user not found」エラーが発生する場合は、HBA ルールに ldapsearchfilter が含まれているか確認します。このパラメーターは必須です。設定されていないと、LDAP 検索がエラーを返さずに失敗したり、結果が返されなかったりする場合があります。

安全上の考慮事項

SSO の設定ミスにより、ユーザーが締め出される可能性があります。 SSO が必須になっている状態で IdP が停止したり、設定に誤りがあったりすると、誰もログインできなくなります。

緩和策 — 緊急用アカウント：

1. SSO を必須にする前に、少なくとも 1 つの組織管理者アカウントがパスワード認証を使用していることを確認します
2. 緊急用アカウントの認証情報を、安全な保管庫（例：1Password、HashiCorp Vault）に記録します
3. 緊急用アカウントが引き続き機能することを確認するため、定期的にテストします
4. SQL SSO（JWT または LDAP）の場合は、フォールバックとしてパスワード認証を使用する SQL ユーザーを少なくとも 1 つ残します

HBA の先頭一致優先 — ロックアウトのリスク： HBA ルールは上から順に評価されます。最初に一致したルールが適用されます。つまり、次のようになります。

• 最初のルールを host all all all ldap ... にすると、root を含むすべてのユーザーが LDAP を経由するよう強制されます
• LDAP サーバーが停止すると、管理者アクセスを含むすべての認証が失敗します
• root および管理者ユーザーのパスワードルールは、必ず LDAP ルールより前に配置してください

危険な設定例：

# DANGEROUS — locks out root if LDAP is unavailable
host all all all ldap ...
host all all all password

安全な設定：

# SAFE — root and admins always have password fallback
host all root all password
host all admin_user all password
host all all all ldap ...
host all all all password

SCIM のリスク：

• 大量のプロビジョニング解除： IdP の SCIM 割り当てが誤って削除されると、プロビジョニング済みのすべてのユーザーが無効化される可能性があります。組織全体で有効にする前に、小規模なグループから始めてください。
• 属性マッピングの誤り： 属性マッピングが正しくないと、名前やメールアドレスが誤ったユーザーが作成される可能性があります。最初に 1 人のユーザーでテストしてください。

LDAP/AD のリスク：

• LDAP サーバーが利用できないと認証がブロックされます： LDAP サーバーが停止すると、LDAP で認証するユーザーは接続できません。管理者ユーザー向けに、パスワードベースの HBA ルールを必ずフォールバックとして残してください。
• LDAP バインドには権限を制限したサービスアカウントを使用してください： ldapbinddn アカウントの読み取り専用権限は最小限にしてください。ドメイン管理者アカウントは決して使用しないでください。
• LDAPS を使用しない場合、認証情報が漏えいする可能性があります： TLS を使用しない LDAP では、パスワードが平文で送信されます。本番環境では必ず、server.ldap_authentication.domain.custom_ca を使用して LDAPS（ポート 636）を設定してください。

ロールバック

Cloud Console の SSO 強制を無効にする

1. 緊急用管理者アカウントでログインします
2. Organization Settings > Authentication に移動します
3. パスワードログインを再度有効にするには、Require SSO を無効にします

DB Console の SSO（OIDC）を無効にする

SET CLUSTER SETTING server.oidc_authentication.enabled = false;

SQL/クラスターの SSO（JWT）を無効にする

SET CLUSTER SETTING server.jwt_authentication.enabled = false;

LDAP/AD 認証を無効にする

-- Revert HBA to password-only authentication
SET CLUSTER SETTING server.host_based_authentication.configuration = '
host all all all password
';

ユーザーの自動プロビジョニングを無効にする

-- Disable JWT auto-provisioning
SET CLUSTER SETTING security.provisioning.jwt.enabled = false;

-- Disable LDAP auto-provisioning
SET CLUSTER SETTING security.provisioning.ldap.enabled = false;

SCIM を無効にする

1. Organization Settings > Authentication > SCIM に移動します
2. SCIM エンドポイントを無効にします
3. IdP から SCIM 統合を削除します

ID マッピングを削除する

SET CLUSTER SETTING server.identity_map.configuration = '';

参考資料

スキルの参考資料：

• IdP の設定手順

関連スキル：

• auditing-cloud-cluster-security — セキュリティ体制の包括的な監査を実行します
• enforcing-password-policies — SSO の代替としてパスワードポリシーを強化します
• managing-tls-certificates — SSO の代替として証明書ベースの認証を使用します

CockroachDB 公式ドキュメント：

• Cloud Console SSO
• DB Console SSO
• クラスターの SSO（JWT）
• SCIM プロビジョニング
• クラスター設定
• HBA の設定
• JWT 認証
• LDAP 認証
• 認証リファレンス