Area: Best Practices
Sub-Area: Access Control & Permissions
Issue
Organizations that need to restrict which assets specific users or groups can discover and view in DataHub often struggle to implement effective fine-grained access control. Simply applying Metadata Policies is not sufficient on its own — users who have a DataHub platform role (such as Reader) retain broad search and browse visibility across the catalog. To fully enforce asset-level visibility restrictions using Search Access Controls, users must be configured without a default DataHub role, and Metadata Policies must be used to explicitly grant access to permitted assets. This approach requires careful coordination, especially in environments that provision users via SCIM or an identity provider such as Microsoft Entra ID (formerly Azure AD), where default role assignments may be applied automatically.
You Might Be Asking
- How do I prevent certain users from seeing assets they are not authorized to access in DataHub search results?
- Why can users still see restricted assets in search even after I applied a Metadata Policy?
- How do Search Access Controls work in DataHub, and what is required to enable them?
- How do I use SCIM or Entra ID to provision users without assigning them a default DataHub role?
- What is the difference between a Metadata Policy and a platform role in controlling asset visibility?
Solution
-
Understand the access control model.
DataHub has two distinct layers of access control:
- Platform Roles (e.g., Admin, Editor, Reader): Broad permissions that govern what actions a user can take across the platform. A user with the Reader role can search and view all assets by default.
- Metadata Policies: Fine-grained policies that grant specific privileges (e.g., View Entity Page, Search & Browse) on specific assets or asset groups to specific users or groups.
Search Access Controls (fine-grained search filtering) only take effect when a user has no assigned DataHub platform role. If a user holds any role, the role's permissions take precedence and may override asset-level restrictions.
-
Enable Search Access Controls in your DataHub configuration.
Ensure that fine-grained search access controls are enabled in your DataHub deployment. Add or confirm the following setting in your application configuration:
# In your DataHub application configuration (e.g., application.yaml or environment variables) SEARCH_AUTHORIZATION_ENABLED=trueFor Helm-based deployments, this is typically set under the
datahub-frontendordatahub-gmsconfiguration block. Refer to your deployment's environment variable documentation for the exact key. -
Ensure target users have NO assigned DataHub platform role.
This is the most critical requirement. Any user who should be subject to asset-level visibility restrictions must not have a platform role assigned. To verify or remove a role:
- Navigate to Settings > Users & Groups > Users in the DataHub UI.
- Select the user and confirm that no role is listed, or remove any existing role assignment.
Users with no role will have zero access by default. All access must then be explicitly granted via Metadata Policies (see step 4).
-
Create Metadata Policies to grant access to permitted assets.
For each group of users that should have access to a specific set of assets:
- Navigate to Settings > Permissions > Policies and click Create Policy.
- Set the policy type to Metadata.
- Select the relevant privileges. At minimum, include:
- View Entity Page — allows users to open an asset's profile page.
- Search & Browse — allows assets to appear in search results and the browse sidebar.
- Scope the policy to the specific assets, asset types, tags, domains, or containers that the group is permitted to access.
- Assign the policy to the relevant users or groups.
Example Policy (conceptual representation): --- Type: Metadata Policy Privileges: - View Entity Page - Search & Browse Resources: - Type: Dataset Filter: Domain = "Finance" Actors: - Group: finance-analysts -
Handle SCIM / Entra ID provisioning without default role assignment.
When using SCIM provisioning (e.g., via Microsoft Entra ID), users may be automatically assigned a default DataHub role upon provisioning, which would bypass Search Access Controls. To prevent this:
- Option A — Remove default role from SCIM configuration: Review your SCIM provisioning application settings and remove any default role mapping so that users are created in DataHub with no role.
-
Option B — Use the DataHub API to remove roles post-provisioning: After users are provisioned, use the DataHub GraphQL API or REST API to remove their role assignment programmatically as part of an automation workflow.
# Example: Remove a platform role from a user via GraphQL mutation removeRole { removeRole( input: { roleUrn: "urn:li:dataHubRole:Reader" actors: [ { type: CORP_USER, identity: "urn:li:corpuser:<username>" } ] } ) } - Option C — Assign users to a DataHub Group with no role, and manage all access through Metadata Policies assigned to that group. Avoid assigning the group a platform role.
-
Validate the configuration end-to-end.
- Log in as a test user who has no role assigned.
- Confirm that assets outside the scope of any Metadata Policy granted to that user do not appear in search results or the browse sidebar.
- Confirm that assets within the permitted scope do appear and are accessible.
- If assets are still visible that should be restricted, re-check whether the user has any role assigned (including via group inheritance).
Additional Notes
Search Access Controls with no-role users represent a default-deny posture: users see nothing unless explicitly granted access via a Metadata Policy. This is intentional and is the correct behavior. Ensure that all necessary privileges (including the ability to log in and navigate the UI) are covered by Metadata Policies before rolling this out to production users, to avoid inadvertently locking users out of all content. Platform-level policies (e.g., allowing users to manage their own profile) can be granted independently of asset-level Metadata Policies and do not affect Search Access Controls. This feature and behavior applies to DataHub Cloud (Acryl) and self-hosted DataHub instances with fine-grained access controls enabled. Always test role and policy changes in a non-production environment before applying them broadly.
Related Documentation
- Access Policies Guide
- DataHub Roles
- Fine-Grained Access Control
- Setting Up SCIM Provisioning
- GraphQL API Overview
Tags: access-control, search-access-controls, metadata-policy, no-role-user, SCIM, Entra-ID, fine-grained-permissions, asset-visibility, platform-role, governance