RBAC Initialization#

Overview#

Dify's enterprise RBAC system requires initialization at two lifecycle points:

1. Resource Creation#

When an App or Dataset is created, a three-step initialization sequence runs:

1. AppAccess/DatasetAccess.replace_whitelist(automatic_include_workspace_members=True) — seeds the access-control whitelist so the resource is visible to all authorized members.
2. try_sync_creator_access_policy_member_bindings — wires the creator into any applicable access-policy group.
3. initialize_created_app_rbac_access_task (async Celery task) — backfills RBAC member bindings for the new resource.

This sequence is only wired into the primary console create controllers. Every other creation entry point constructs the App/Dataset object directly and skips it, leaving the resource with no RBAC access record. Non-maintainer team members get 403 when opening those resources because the maintainer/creator short-circuit hides the gap from the creator. 1

2. Workspace Member Join#

When a new member joins a workspace, sync_joined_workspace_member_rbac_access_task scans all apps and datasets in the workspace to find those with automatic_include_workspace_members=True and adds the new member to their whitelists. This task only runs for new memberships (not role updates), when RBAC is enabled, for non-owner roles, and for active accounts (not pending).

Tracking issue: #39379 — opened 2026-07-21.

Where RBAC Init Is (and Isn't) Wired In#

Workspace Member Join Path#

When create_tenant_member creates a new membership (membership_created=True), RBAC is enabled, the role is not OWNER, and the account is not PENDING, it dispatches sync_joined_workspace_member_rbac_access_task. The task uses the operator_account_id (who invited the member) as the actor for RBAC API calls, falling back to the workspace owner if not provided.

Processing flow:

1. Iterates through all apps and datasets in batches of 500 resources
2. For each batch, fetches whitelist configs via ResourceWhitelistConfigs.batch_get
3. Filters for resources with automatic_include_workspace_members=True
4. Appends the new member to filtered resources' whitelists in batches of 500 using AppAccess.append_whitelist_members_batch and DatasetAccess.append_whitelist_members_batch
5. Uses the default policy ID for all access grants

App Creation Paths#

Console create calls AppService.create_app, which calls enterprise_rbac_service.try_sync_creator_access_policy_member_bindings 2, then calls RBACService.AppAccess.replace_whitelist with automatic_include_workspace_members=True, and dispatches initialize_created_app_rbac_access_task.

Agent App create (AgentAppListApi.post in roster.py) calls AppService.create_app — which includes try_sync_creator_access_policy_member_bindings — but does not call RBACService.AppAccess.replace_whitelist or dispatch initialize_created_app_rbac_access_task, leaving RBAC initialization incomplete.

DSL import (AppDslService._create_or_update_app) fires app_was_created and sets up the App model, but returns without any RBAC call 3. The same import_app code path is reused by inner_api/app/dsl.py and openapi/app_dsl.py — none of those endpoints initialize RBAC.

Agent duplication (AgentRosterService.duplicate_agent_app) delegates to AppService.create_app — which does call try_sync_creator_access_policy_member_bindings 4 — but the controller that calls duplicate_agent_app does not separately dispatch initialize_created_app_rbac_access_task or call RBACService.AppAccess.replace_whitelist. 1

Workflow conversion (WorkflowConverter.convert_to_workflow) creates a bare App, commits, fires app_was_created, and returns with no RBAC calls. 5

Dataset Creation Paths#

1

Additional Dataset Complication#

For datasets there is a second layer: check_dataset_permission reads the legacy dataset.permission / DatasetPermission model, which the RBAC access-config UI does not update. A knowledge base created via file upload defaults to permission=only_me and has no RBAC whitelist, so assigning "Partial team members" in the RBAC UI still fails — the legacy gate rejects first with You do not have permission to access this dataset. 1

The console empty-dataset create path forces permission=ALL_TEAM to make the legacy gate a pass-through; non-console paths do not. 1

RBAC_ENABLED guard: PR #41022 added an if not dify_config.RBAC_ENABLED guard around check_dataset_permission() in the dataset GET endpoint (api/controllers/console/datasets/datasets.py), ensuring the legacy permission check is bypassed when RBAC is enabled. Other call sites (8 in datasets_document.py) still invoke check_dataset_permission without this guard.

Root Cause#

The RBAC-on-create logic is duplicated inline inside multiple controllers rather than extracted into a shared helper. Each additional creation entry point added afterward silently omits the call. 1

Three open design questions from the tracking issue:

1. Should all creation paths (App ×5, Dataset ×6) call a shared apply_<resource>_creation_rbac() helper?
2. Should check_dataset_permission be gated behind if not RBAC_ENABLED, or should non-console create paths force permission=ALL_TEAM? Resolved — PR #41022 implemented the RBAC_ENABLED guard in the dataset GET endpoint; the decision to gate the legacy check has been made at least for that code path.
3. Should inner_api / openapi DSL-import endpoints also initialize RBAC?

Key Files#

Related Issues#

• #39379 — Primary tracking issue with coverage matrix and reproduction steps 1
• #39037 — Earlier report: "some path miss rbac sync" (maintainer-filed)
• #37988 — Parent enhancement: resource-level permission consistency
• #39226 — Dataset-specific: syncing RBAC for partial_members/only_me permissions