Azure Databricks Scim Provisioning Connector
You set up the azure databricks scim provisioning connector by linking your cloud directory to your workspace. This link pushes user and group updates straight into your data platform on a timer. Most data teams start by mapping broad directory groups to workspace roles. They do this to get analysts working fast without manual steps. Still, broad group roles often give users far more table permissions than they need. One wide role can let an analyst read or change sensitive tables by mistake.
Azure RBAC + User Provisioning (SCIM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up the azure databricks scim provisioning connector by linking your cloud directory to your workspace. This link pushes user and group updates straight into your data platform on a timer. Most data teams start by mapping broad directory groups to workspace roles. They do this to get analysts working fast without manual steps. Still, broad group roles often give users far more table permissions than they need. One wide role can let an analyst read or change sensitive tables by mistake.
How the azure databricks scim provisioning connector works
SCIM stands for System for Cross-domain Identity Management. It is an open standard that moves user data between cloud tools. In this setup, your directory acts as the single source of truth. You create an enterprise app in your directory to handle the sync. Then you link that app to your account console or workspace endpoint. You give the directory a secret token or use managed account credentials.
Once linked, the directory checks for changes on a fixed schedule. When a new engineer joins a team, you add them to a directory group. The connector sees this change and creates the matching user in the data platform. It also places that user into the right workspace group right away. When someone leaves the company, you disable their profile in the directory. On the next sync cycle, the connector removes their workspace access too.
Admins can choose between account-level sync and workspace-level sync. Account-level sync sends all users and groups to one central hub first. From that hub, you assign specific groups to individual workspaces as needed. Workspace-level sync sends user profiles straight to one single workspace instead. Most large teams prefer the central account method to avoid setting up many links.
What directory sync solves and what it leaves open
Directory sync removes the pain of adding and deleting users by hand. Security teams do not have to chase down stray accounts across ten workspaces. When an employee leaves, cutting off their main directory profile stops workspace logins. It also keeps group names the same across your directory and data tools. Auditors like this because they can review group lists in one central place.
Yet directory sync only controls who can enter the room. It does not check what a user does once they log in. A user in an approved group still gets full standing permissions all day. If an analyst runs a wide query, the platform returns all matching rows. Those rows might hold raw customer emails, phone numbers, or card numbers. Directory sync cannot rewrite those sensitive fields in query results on the fly.
Azure RBAC + User Provisioning (SCIM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Sync tools also cannot pause a risky command to ask for a manager review. If a user has write rights, they can drop a table right now. Also, sync intervals take time to run and finish. A permission change in your directory might wait until the next sync cycle. Teams need runtime controls to inspect queries and mask fields during live sessions.
Best practices for group and role design
Start by keeping your directory groups small and focused on single job tasks. Do not dump every data user into one giant analysts group. Split groups by department, project, and whether they need read or write rights. Map those narrow groups to catalog roles that only touch specific schemas.
Keep admin groups separate from daily work groups. Even senior engineers should use a basic read role for routine checks. Review your synced groups every quarter to prune stale members and unused workspaces. Clean group design makes your runtime security rules much easier to manage.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Should I set up SCIM at the account level or workspace level?
Set up SCIM at the central account level whenever you can. This lets you manage users once and assign them to any workspace easily.
What happens when I remove a user from the synced directory group?
The connector marks the user as inactive on the next sync run. That person loses their login access, while their past jobs remain for audit logs.
Does SCIM provisioning control table permissions and data masking?
No, SCIM only syncs user identities and group lists into your account. You must use catalog permissions or runtime controls to limit queries and mask data.