アカウントSCIMを使用してID属性を管理する

アカウントの System for Cross-domain Identity Management（SCIM）2.1 API は、プロビジョニングコネクタ経由、または直接、9つのID属性をDatabricksアカウントユーザーにプロビジョニングします。

備考

ベータ版

この機能はベータ版です。アカウント管理者は、アカウントコンソールの [プレビュー] ページから、この機能へのアクセスを管理できます。「アカウントレベルのプレビューを管理する」を参照してください。

Databricksでは、ID属性の管理にはSCIMよりも自動ID管理を推奨しています。詳細については、「自動ID管理」を参照してください。

前提条件

アカウント管理者である必要があります。
アカウントレベルのSCIMプロビジョニングをアカウントに設定します。「ユーザーとグループをDatabricksアカウントに同期する」を参照してください。
ID属性は、https://accounts.cloud.databricks.com/api/2.1/accounts/<account-id>/scim/v2/ の account SCIM 2.1 で管理されます。これは、属性の完全なセットを読み書きする唯一のインターフェースです。
SCIMを通じて属性を書き込むために、 ID属性コントロールリスト の機能プレビューを有効にする必要はありません。プレビューが有効な場合は、プッシュしようとしている属性がアカウントの属性コントロールリストに含まれていることを確認してください。含まれていない場合、書き込みは拒否されます。ID属性コントロールリストを参照してください。

SCIMコネクタの構成

ID 属性は、属性をプッシュする SCIM プロビジョニングコネクタ、または属性をプルする自動 ID 管理のいずれかを通じて、ID プロバイダーから Databricks に到達します。このセクションでは、Okta および Microsoft Entra ID のコネクタルートについて説明します。

どちらのプロバイダーでも作業の概要は同じです。プロバイダーの送信スキーマを拡張して9つのDatabricks属性が存在することを認識させ、それぞれをユーザープロファイルのソース属性にマップしてから同期します。既存のSCIMコネクタアプリケーションを更新してこれを行うことができます。IDプロバイダーで新しいアプリを作成する必要はありません。

Okta

まず、Databricksの標準的なOktaセットアップに従って、Databricks SCIMコネクタアプリケーションを作成します。次に、そのアウトバウンドスキーマを拡張します。

Applications > お使いのDatabricksアプリケーション > プロビジョニング > To App に移動し、 Go to Profile Editor を開きます。
属性を追加 を選択し、以下の表にある9つの属性を追加してください。9つすべてがデータ型 文字列 です。
外部名前空間 については、最初の5つの属性（役職から勤務国まで）にはurn:ietf:params:scim:schemas:core:2.0:Userを、最後の4つの属性（コストセンターから部門まで）にはurn:ietf:params:scim:schemas:extension:enterprise:2.0:Userを使用してください。
Provisioning tabに戻り、 Mappings セクションを編集して、各Databricks属性を、参照先となるOktaユーザープロファイル属性にマップします。

External name と External namespace は Okta が通信で送信する値であるため、SCIM パスと完全に一致している必要があります。

表示名	変数名	外部名
タイトル	`title`	`title`
ユーザータイプ	`userType`	`userType`
作業の局所性	`workLocality`	`addresses.^[type=='work'].locality`
勤務リージョン	`workRegion`	`addresses.^[type=='work'].region`
勤務国	`workCountry`	`addresses.^[type=='work'].country`
コストセンター	`costCenter`	`costCenter`
組織	`organization`	`organization`
部門	`division`	`division`
部門	`department`	`department`

表示名	変数名	外部名
タイトル	`title`	`title`
ユーザータイプ	`userType`	`userType`
作業の局所性	`workLocality`	`addresses.^[type=='work'].locality`
勤務リージョン	`workRegion`	`addresses.^[type=='work'].region`
勤務国	`workCountry`	`addresses.^[type=='work'].country`
コストセンター	`costCenter`	`costCenter`
組織	`organization`	`organization`
部門	`division`	`division`
部門	`department`	`department`

結果をテストするには、 Directory > People > Add person でユーザーを作成し、プロファイルにマップされた属性を設定してから、 Assignments tabでそのユーザーをアプリケーションに割り当てます。 プロビジョニング tab を開き、属性をすぐに同期する必要がある場合は 強制同期 を選択します。属性は、約5分以内にDatabricksアカウントコンソールのユーザーに表示されます。

Oktaコネクタは次のように動作します：

属性値は 大文字と小文字を区別 し、送信されたとおりに正確に保存されます。
_、-、.の記号およびスペースは問題なく同期されます。
配列値の属性はサポートされていません。 マッピングを行うとOktaでエラーが発生し、Databricksの値は変更されないままになります。これは、単一要素の配列にも適用されます。

Microsoft Entra ID

Databricks向けの標準的なMicrosoft Entra IDセットアップに従って、Microsoft Entra IDでSCIMプロビジョニングアプリケーションを作成します。

スキーマエディターはdefaultでは公開されていません。?Microsoft_AAD_Connect_Provisioning_forceSchemaEditorEnabled=true をポータルURLの末尾に追加し、構成セッション全体を通してその設定を維持してください。これがないと、 [スキーマを編集] オプションは表示されません。

アプリケーションを開き、 プロビジョニング > Attribute mapping に移動します。
[詳細オプション] で、 [Databricks ユーザー属性の編集] を選択します。
以下の 9 つの属性を追加します。すべて 文字列 型です：
- title
- userType
- addresses[type eq "work"].locality
- addresses[type eq "work"].region
- addresses[type eq "work"].country
- urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:costCenter
- urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:organization
- urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:division
- urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department
属性マッピング画面に戻り、各属性に対して Direct マッピングタイプと次の表のソース属性を使用して、 属性マッピングを追加 を選択します。

Microsoft Entra IDには、コストセンターや部門に対応するネイティブのソースフィールドがないため、それらをバインドするための適切なカスタム拡張属性や式がない限り、これら2つはマッピングしないままにしてください。

Databricks ターゲット	Microsoft Entra IDソース属性
`title`	`jobTitle`
`userType`	`employeeType`
`addresses[type eq "work"].locality`	`city`
`addresses[type eq "work"].region`	`state`
`addresses[type eq "work"].country`	`country`
`...:enterprise:2.0:User:organization`	`companyName`
`...:enterprise:2.0:User:department`	`department`
`...:enterprise:2.0:User:costCenter`	マッピングされていません
`...:enterprise:2.0:User:division`	マッピングされていません

Databricks ターゲット	Microsoft Entra IDソース属性
`title`	`jobTitle`
`userType`	`employeeType`
`addresses[type eq "work"].locality`	`city`
`addresses[type eq "work"].region`	`state`
`addresses[type eq "work"].country`	`country`
`...:enterprise:2.0:User:organization`	`companyName`
`...:enterprise:2.0:User:department`	`department`
`...:enterprise:2.0:User:costCenter`	マッピングされていません
`...:enterprise:2.0:User:division`	マッピングされていません

テストするには、 Users > New User でユーザーを作成し、マップされたフィールドに入力します。 プロビジョニング > Users and グループ でアプリケーションに追加し、 Provision on demand を開いてユーザーを選択します。その後、属性は Databricks アカウントコンソールのユーザーの Identity attributes tab に表示されます。Microsoft Entra ID ユーザーの属性値を消去し、オンデマンドで再度プロビジョニングを行うと Databricks 内の値も削除されるため、両側で同期が保たれます。

注記

以前は正常に動作していたコネクターが、ID属性コントロールリストの有効化または絞り込み後に失敗し始めた場合、その原因のほとんどは、アカウントで許可されなくなった属性をコネクターが依然としてプッシュしていることにあります。Databricks は 400 を伴ってリクエスト全体を拒否するため、部分的に適用されるのではなく同期が失敗します。これを修正するには、属性をコントロールリストに戻すか、コネクターのマッピングからその属性を削除してから、同期を強制的に再実行します。変更されていない値をコネクターが再プッシュしても拒否されません。これは、適用が実際に変更された値に対してのみ行われるためです。ID属性コントロールリストを参照してください。

SCIM API を使用した属性の管理

ID 属性はアカウント SCIM 2.1 で管理されます。5 つの属性は SCIM コア User スキーマにあり、残りの 4 つは標準エンタープライズユーザー拡張機能にあります。その URN は urn:ietf:params:scim:schemas:extension:enterprise:2.0:User です。

属性	SCIM における場所
`title`	コアユーザー： `title`
`userType`	コアユーザー： `userType`
`locality`	コアユーザー： `addresses[type eq "work"].locality`
`region`	コアユーザー： `addresses[type eq "work"].region`
`country`	コアユーザー： `addresses[type eq "work"].country`
`costCenter`	エンタープライズ拡張機能: `costCenter`
`organization`	エンタープライズ拡張機能: `organization`
`division`	エンタープライズ拡張機能: `division`
`department`	エンタープライズ拡張機能: `department`

属性	SCIM における場所
`title`	コアユーザー： `title`
`userType`	コアユーザー： `userType`
`locality`	コアユーザー： `addresses[type eq "work"].locality`
`region`	コアユーザー： `addresses[type eq "work"].region`
`country`	コアユーザー： `addresses[type eq "work"].country`
`costCenter`	エンタープライズ拡張機能: `costCenter`
`organization`	エンタープライズ拡張機能: `organization`
`division`	エンタープライズ拡張機能: `division`
`department`	エンタープライズ拡張機能: `department`

リクエストおよびレスポンスにおいて、4つのエンタープライズ属性は、その完全修飾パスによって指定されます。たとえば、urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:costCenter。

ID 属性を持つユーザーの作成

Text
POST /api/2.1/accounts/<account-id>/scim/v2/Users
Authorization: Bearer <token>
Content-Type: application/scim+json

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "jane.doe@example.com",
  "displayName": "Jane Doe",
  "title": "Staff Engineer",
  "userType": "Employee",
  "addresses": [
    { "locality": "Mountain View", "region": "CA", "country": "US" }
  ],
  "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
    "costCenter": "4130",
    "organization": "Databricks",
    "division": "Platform",
    "department": "Identity"
  }
}

Databricks は 201 Created で完全なユーザーレコードを返します。レスポンスの形状には、次の特性があります。

schemas エンタープライズ属性が設定されていない場合でも、常にコアUser URNとエンタープライズ拡張URNの両方をアドバタイズします。
保存された値を持たない属性は、nullとして返されるのではなく、完全に省略されます。
ユーザーごとに1つのアドレスのみが保存されるため、addresses は常に単一の要素を保持します。Databricksは自動的に "type": "work" と "primary": true をスタンプします。これらは両方とも読み取り専用であり、IDプロバイダーからマッピングすることはできません。
アカウントSCIM 2.1は、ユーザーに関する meta または entitlements を返しません。

ID 属性を読み取る

Text
GET /api/2.1/accounts/<account-id>/scim/v2/Users/<user-id>
Authorization: Bearer <token>

この応答は、作成応答と同じ形式です。読み取りは、 属性コントロールリストによってフィルタリングされることはありません 。以前に保存された属性は、コントロールリストから削除された後も GET 上で完全に表示されたままになります。書き込みのみが制限されます。

ID属性を更新する

3つのPATCH操作形式（add、replace、およびremove）はすべて、完全修飾エンタープライズパスを含むすべての属性に対して機能します。

Text
PATCH /api/2.1/accounts/<account-id>/scim/v2/Users/<user-id>
Authorization: Bearer <token>
Content-Type: application/scim+json

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    { "op": "replace", "path": "title", "value": "Principal Engineer" },
    { "op": "replace", "path": "userType", "value": "Contractor" },
    {
      "op": "replace",
      "path": "addresses",
      "value": [{ "locality": "Seattle", "region": "WA", "country": "US" }]
    },
    {
      "op": "replace",
      "path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:costCenter",
      "value": "9001"
    }
  ]
}

Databricks は更新されたユーザーとともに 200 OK を返します。addresses は複雑な値全体として置き換えられるため、保持したいすべてのサブフィールドを送信してください。上記の値から country を省略すると、その値は消去されます。

ID属性の削除

Text
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    { "op": "remove", "path": "userType" },
    {
      "op": "remove",
      "path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:division"
    }
  ]
}

Databricks は 200 OK を返し、削除された属性はユーザーレコードに表示されなくなります。削除は 属性コントロールリストに関係なく常に成功します 。そのため、管理者は、アカウントによる書き込みが許可されなくなった属性を含め、保存された値をいつでも削除できます。

属性コントロールリストが書き込みを拒否した場合

アカウントがIdentity Attribute Control Listプレビューに登録されると、リストにない属性の書き込みは拒否されます。たとえば、userTypeがリストにない状態で{"op": "replace", "path": "userType", "value": "Vendor"}を送信すると、400 Bad Requestが返されます：

JSON
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
  "status": "400",
  "scimType": "invalidValue",
  "detail": "The following identity attributes are not on this account's attribute control list and cannot be created or updated: userType. Add them to the control list, or remove them from the request. Existing values can still be removed."
}

統合する前に、以下の強制動作を理解しておいてください：

強制適用はスキーマ単位ではなく、属性単位で行われます。 division のようなリスト外のエンタープライズ属性は、同じリクエスト内の他のエンタープライズ属性が許可されている場合でも拒否されます。
PATCH はアトミックです。 リスト外の属性を対象とする操作が含まれている場合、リクエスト全体が拒否され、許可されている変更も一切適用されません。ユーザーレコードが変更される前に検証ランが実行されます。
変更された値のみがチェックされます。 保存されている値と同じ値を再送信しても何も実行されず（no-op）、リスト外の属性であっても通過します。これは、同期のたびに変更されていない値を再プッシュするIDプロバイダーコネクタにとって重要です。
アドレスのサブフィールドは個別にチェックされます。 locality、region、およびcountryには、それぞれ独自のコントロールリストエントリが必要です。

リストの構成方法については、ID属性コントロールリストを参照してください。

サポートされている属性を確認する

GET /api/2.1/accounts/<account-id>/scim/v2/Schemas SCIM ListResponse を返します。ID属性がサーフェスに対して有効になっている場合、User（このページで説明されている追加属性をサポート）、グループ、ServicePrincipal、およびエンタープライズユーザー拡張機能という4つのスキーマリソースが含まれます。

コアユーザーのスキーマは、title、userType、および addresses をアドバタイズします。addresses 内では、3つのIDプロバイダーソースのサブ属性は readWrite ですが、type と primary は Databricks によって設定されるため readOnly となります：

JSON
{
  "name": "addresses",
  "type": "complex",
  "multiValued": true,
  "description": "A physical mailing address for this user.",
  "mutability": "readWrite",
  "returned": "default",
  "subAttributes": [
    { "name": "locality", "type": "string", "mutability": "readWrite" },
    { "name": "region", "type": "string", "mutability": "readWrite" },
    { "name": "country", "type": "string", "mutability": "readWrite" },
    { "name": "type", "type": "string", "mutability": "readOnly", "canonicalValues": ["work"] },
    { "name": "primary", "type": "boolean", "mutability": "readOnly" }
  ]
}

エンタープライズ拡張機能は GET /api/2.1/accounts/<account-id>/scim/v2/Schemas/urn:ietf:params:scim:schemas:extension:enterprise:2.0:User で単独で解決可能であり、4つのエンタープライズ属性を readWrite 文字列として返します：

JSON
{
  "id": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
  "name": "EnterpriseUser",
  "description": "Enterprise User",
  "attributes": [
    { "name": "costCenter", "type": "string", "mutability": "readWrite" },
    { "name": "department", "type": "string", "mutability": "readWrite" },
    { "name": "division", "type": "string", "mutability": "readWrite" },
    { "name": "organization", "type": "string", "mutability": "readWrite" }
  ],
  "meta": { "resourceType": "Schema" }
}

/Schemas の出力は静的です。これは、属性コントロールリストや個々のユーザーが設定した内容の影響を受けません。これは、そのサーフェスが ID 属性を管理しているかどうかのみを反映します。

独自の属性を読み取る

ワークスペース用のアカウント SCIM は、https://<workspace-host>/api/2.0/account/scim/v2/ のワークスペースホストから提供されます。このインターフェースでは、読み取りまたは書き込み時にID属性は公開されず、ワークスペース管理者は他のユーザーのID属性を読み取ったり変更したりすることは許可されていません。

警告

このサーフェス上のID属性への書き込みは2xxを返しますが、拒否されるのではなく 警告なしに破棄 されます。成功の応答が返されたからといって、属性が保存されたとは限りません。ID属性を書き込むには、アカウントSCIM 2.1を使用してください。SCIM APIによる属性の管理を参照してください。

/Me が唯一の例外です。呼び出し元自身のプロファイルのみが返されるため、ユーザーはそこで自身の ID 属性を読み取ることができます：

Text
GET /api/2.0/account/scim/v2/Me
Authorization: Bearer <workspace-token>

JSON
{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User",
    "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
  ],
  "id": "1234567890123456",
  "userName": "jane.doe@example.com",
  "displayName": "Jane Doe",
  "active": true,
  "emails": [{ "type": "work", "primary": true, "value": "jane.doe@example.com" }],
  "name": { "givenName": "Jane", "familyName": "Doe" },
  "title": "Staff Engineer",
  "userType": "Employee",
  "addresses": [
    {
      "locality": "Mountain View",
      "region": "CA",
      "country": "US",
      "type": "work",
      "primary": true
    }
  ],
  "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
    "costCenter": "4130",
    "organization": "Databricks",
    "division": "Platform",
    "department": "Identity"
  },
  "groups": [{ "value": "987654321098765", "display": "engineering" }]
}

/Me については、次の点に注意してください：

/Me はここでは読み取り専用です。POST、PUT、PATCH、および DELETE は、以下とともに 501 を返します： "detail": "Endpoint not supported."
groups 管理ユーザーによる読み取りとは異なり、/Me では常に返されます。
属性コントロールリストは /Me には影響しません。これは、リストが書き込みを管理しており、/Me は書き込みを行えないためです。
ワークスペースレベルのSCIM (/api/2.0/preview/scim/v2/) は異なるAPIであり、独自の /Me を含め、どのEndpointでもアカウントレベルのID属性を公開することはありません。

前提条件​

SCIMコネクタの構成​

Okta​

Microsoft Entra ID​

SCIM API を使用した属性の管理​

ID 属性を持つユーザーの作成​

ID 属性を読み取る​

ID属性を更新する​

ID属性の削除​

属性コントロールリストが書き込みを拒否した場合​

サポートされている属性を確認する​

独自の属性を読み取る​