Skip to main content
Last updated on

Identity attributes

Identity attributes are a fixed set of nine attributes that Databricks stores on account users and sources from your identity provider (IdP). Account admins provision them so the values can be referenced in Unity Catalog ABAC policies.

Beta

This feature is in Beta. Account admins can manage access to this feature from the account console Previews page. See Manage account-level previews.

warning

Do not use identity attributes to store sensitive information.

To ingest identity attributes with automatic identity management, or to restrict which attributes can be written to your users, an account admin must enable the Identity Attribute Control List feature preview. This preview is off by default and is enabled from the account console Previews page. See Manage account-level previews.

Overview​

Identity attributes are nine IdP-sourced fields that Databricks stores on an account user: title, userType, locality, region, country, costCenter, organization, division, and department. Databricks keeps these attributes in sync with your identity provider so that the values on a user reflect the source of record in your IdP.

Identity attributes exist so that you can reference user characteristics elsewhere in Databricks. In Beta, you can use them in Unity Catalog attribute-based access control (ABAC) policies for column masking, such as masking a column unless the user's country attribute matches the data's country. For more information about ABAC, see Attribute-based access control in Unity Catalog.

note

The Unity Catalog ABAC policy functions that consume identity attributes are delivered separately from this feature. This page covers only how identity attributes are provisioned, stored, and read.

For where each attribute maps in the SCIM core User schema and the enterprise user extension, see Manage identity attributes with account SCIM.

How it works​

Identity attributes are provisioned from your identity provider, stored on the account user, and read back through the account console and the account SCIM APIs.

Ingest identity attributes​

Identity attributes reach Databricks from your identity provider in one of two ways:

  • Automatic identity management pulls attributes from your identity provider on a schedule. This is the recommended, go-forward mechanism. For more information, see Automatic identity management.
  • Account SCIM 2.1 pushes attributes from a provisioning connector or a direct API call.

On AWS and GCP, you can ingest identity attributes using either mechanism. Databricks recommends automatic identity management, which keeps attributes in sync with your identity provider faster than the SCIM-based model. SCIM-based management of these attributes is discouraged; Databricks focuses new attribute support on automatic identity management. To manage identity attributes with account SCIM, see Manage identity attributes with account SCIM.

Control which attributes are stored​

The attribute control list is an account-level allowlist that governs which of the nine attributes may be written to users in your account. When automatic identity management is enabled, each sync also reconciles a user's stored attributes against the list. For details, including how the list is enforced, see Identity Attribute Control List.

Read identity attributes​

Account admins can read any user's identity attributes through account SCIM 2.1 with GET /Users/<id>. Any user can read their own attributes through the account-SCIM-for-workspaces /Me endpoint (https://<workspace-host>/api/2.0/account/scim/v2/Me), which is read-only. Workspace admins can't read or modify other users' identity attributes. Reads are never filtered by the attribute control list, so a value stored before an attribute was removed from the list stays fully visible.

Attribute changes in your identity provider are not reflected in Databricks instantly. When a user signs in, automatic identity management refreshes that user's attributes within about five minutes. Because Unity Catalog evaluates policies for signed-in users, an active user's policy decisions use these recently synced values. Users who have not signed in or otherwise had an automatic identity management sync triggered are refreshed within five days by a periodic background sync.

View a user's identity attributes​

You can view the identity attributes stored on a user in the account console, so you can confirm what actually landed without calling the SCIM API.

  1. As an account admin, log in to the account console.
  2. In the sidebar, click User management.
  3. On the Users tab, find and click the user.
  4. Click the Identity attributes tab.

The tab lists all nine attributes. Keep the following in mind when you read it:

  • It is read-only. Identity attributes are IdP-sourced, so you can't edit them here. Change them at the source, through your identity provider, and the tab reflects the new value on the next load.
  • Every attribute is always listed. An attribute with no stored value shows an en dash (–) rather than being hidden, so you can tell "not set" apart from "set to an unexpected value".
  • The view isn't filtered by the attribute control list. A value stored before an attribute was removed from the list still appears here. This lets you see exactly what data you're holding so you can decide whether to retire it.
  • Values are shown exactly as stored, preserving the case sent by your identity provider.

If the Identity attributes tab doesn't appear on a user's page, the feature isn't enabled for your account, and navigating directly to it returns you to the user's information page.

Limitations​

Identity attributes have the following limitations in Beta:

  • Identity attributes are supported on users only. Service principals and groups are not yet supported.
  • Each attribute holds a single value. The work address is a single object with locality, region, and country. Multi-valued attributes are future work.
  • The attribute control list can only be configured in the account console. There is no API to configure it programmatically.
  • On Azure, self-serve SCIM-based management of identity attributes isn't documented. Azure customers use automatic identity management, or contact their account team for the SCIM API.
  • On Microsoft Entra ID there is no native source field for costCenter or division, so those two attributes stay unmapped unless you supply a custom extension attribute or expression.

Additional resources​

On this page