[GH-ISSUE #23756] feat: Workspace-Level Admin Roles (Scoped RBAC) #58729

New Issue

GiteaMirror · 2026-05-05T23:47:54-05:00

GiteaMirror commented

2026-05-05 23:47:54 -05:00

Originally created by @giovanisp on GitHub (Apr 15, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23756

Check Existing Issues

I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.

Verify Feature Scope

I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

Problem Description

In enterprise environments, Open WebUI lacks a scoped role model for multi-tenant usage.

Currently:

Only Admin users can create and manage workspaces/projects.
Admins have full visibility across all workspaces, knowledge bases, files, and models.
There is no way to delegate workspace-level administration without granting global access.

This creates a blocking issue for enterprise adoption:

Teams cannot autonomously create and manage their own workspaces.
Granting Admin rights violates data isolation and least privilege principles.
Sensitive data in Knowledge Bases or files becomes visible to unintended users.

Typical enterprise requirement:

Multiple teams/projects
Strict isolation between them
Delegated ownership without global visibility

At the moment, this forces:

manual provisioning by global admins, or
unsafe workarounds (over-granting Admin role)

Desired Solution you'd like

Introduce a scoped RBAC model with workspace-level administration.

Proposed roles:

Global Admin
- Full access across all workspaces (current behavior)
Workspace Admin (NEW)
- Scoped to one or more workspaces
- Can:
  - create/manage Knowledge Bases, Skills (maybe even tools?) if permission given by the Global Admin
  - manage files within the workspace/KB
  - optionally configure new CUSTOM models (visibility, defaults) if permission given by the Global Admin
  - manage users/groups within the workspace
- Cannot:
  - access other workspaces
  - view global data outside their scope
User
- Access only assigned workspaces (current behavior)

Required capabilities:

Workspace-scoped visibility
- All entities (KB, files, skills, models, chats) filtered by workspace_id
Delegated workspace creation (optional but important)
- Ability to allow non-admin users to:
  - create a new workspace
  - automatically become its Workspace Admin
Group-based access control
- Integration with external identity providers (e.g., Microsoft Entra ID groups)
- Map groups → workspace roles
Model and KB isolation
- Workspace Admin can:
  - expose/hide models to their workspace
  - manage private Knowledge Bases or Skills / Tools
UI changes
- Workspace Admin sees only:
  - their workspaces
  - their resources
- No global admin panels

Alternatives Considered

Using Global Admin role for selected users
- Rejected: breaks isolation and security model
Manual provisioning by central admin
- Not scalable in organizations with many teams/projects
Multiple Open WebUI instances (one per team)
- Adds operational overhead (infra, updates, monitoring) and costs
- Duplicates resources unnecessarily

Additional Context

This feature is critical for:

enterprise deployments
multi-team environments
regulated contexts where data isolation is mandatory

Example scenario:

Organization with multiple teams/projects
Each team:
- has its own Knowledge Base
- uses different models/configurations
- must not access other teams’ data

Expected behavior:

A team lead creates a workspace
Becomes Workspace Admin
Manages users, KB, sills/tools and models within that workspace only

Current behavior:

Requires Global Admin involvement for anything
Or exposes all data to delegated users

This enhancement would significantly improve Open WebUI’s positioning as an enterprise-ready multi-tenant platform.

Originally created by @giovanisp on GitHub (Apr 15, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/23756 ### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description In enterprise environments, **Open WebUI lacks a scoped role model for multi-tenant usage**. Currently: - Only **Admin** users can create and manage workspaces/projects. - Admins have **full visibility across all workspaces, knowledge bases, files, and models**. - There is **no way to delegate workspace-level administration** without granting global access. This creates a blocking issue for enterprise adoption: - Teams cannot autonomously create and manage their own workspaces. - Granting Admin rights violates **data isolation and least privilege principles**. - Sensitive data in Knowledge Bases or files becomes visible to unintended users. Typical enterprise requirement: - Multiple teams/projects - Strict isolation between them - Delegated ownership without global visibility At the moment, this forces: - manual provisioning by global admins, or - unsafe workarounds (over-granting Admin role) ### Desired Solution you'd like Introduce a **scoped RBAC model with workspace-level administration**. ### Proposed roles: - **Global Admin** - Full access across all workspaces (current behavior) - **Workspace Admin (NEW)** - Scoped to one or more workspaces - Can: - create/manage Knowledge Bases, Skills (maybe even tools?) if permission given by the Global Admin - manage files within the workspace/KB - optionally configure new CUSTOM models (visibility, defaults) if permission given by the Global Admin - manage users/groups within the workspace - Cannot: - access other workspaces - view global data outside their scope - **User** - Access only assigned workspaces (current behavior) ### Required capabilities: 1. **Workspace-scoped visibility** - All entities (KB, files, skills, models, chats) filtered by `workspace_id` 2. **Delegated workspace creation (optional but important)** - Ability to allow non-admin users to: - create a new workspace - automatically become its Workspace Admin 3. **Group-based access control** - Integration with external identity providers (e.g., Microsoft Entra ID groups) - Map groups → workspace roles 4. **Model and KB isolation** - Workspace Admin can: - expose/hide models to their workspace - manage private Knowledge Bases or Skills / Tools 5. **UI changes** - Workspace Admin sees only: - their workspaces - their resources - No global admin panels ### Alternatives Considered - **Using Global Admin role for selected users** - Rejected: breaks isolation and security model - **Manual provisioning by central admin** - Not scalable in organizations with many teams/projects - **Multiple Open WebUI instances (one per team)** - Adds operational overhead (infra, updates, monitoring) and costs - Duplicates resources unnecessarily ### Additional Context This feature is critical for: - enterprise deployments - multi-team environments - regulated contexts where data isolation is mandatory Example scenario: - Organization with multiple teams/projects - Each team: - has its own Knowledge Base - uses different models/configurations - must not access other teams’ data Expected behavior: - A team lead creates a workspace - Becomes Workspace Admin - Manages users, KB, sills/tools and models within that workspace only Current behavior: - Requires Global Admin involvement for anything - Or exposes all data to delegated users This enhancement would significantly improve Open WebUI’s positioning as an enterprise-ready multi-tenant platform.

GiteaMirror closed this issue

2026-05-05 23:47:55 -05:00

GiteaMirror commented

2026-05-05 23:47:57 -05:00

@Classic298 commented on GitHub (Apr 15, 2026):

Desired Solution you'd like
Introduce a scoped RBAC model with workspace-level administration.

Proposed roles:
Global Admin

Full access across all workspaces (current behavior)
Workspace Admin (NEW)

Scoped to one or more workspaces
Can:
create/manage Knowledge Bases, Skills (maybe even tools?) if permission given by the Global Admin
manage files within the workspace/KB
optionally configure new CUSTOM models (visibility, defaults) if permission given by the Global Admin
manage users/groups within the workspace
Cannot:
access other workspaces
view global data outside their scope

There is no user management within the workspace

You can already create a user group, give that user group access to the workspace, and have these users create and manage knowledge bases, set the knowledge bases to public (or only give access to certain groups), and then normal users without access to the workspace area can use the knowledge bases.

Literally all of this is already possible with today's permission system

@Classic298 commented on GitHub (Apr 15, 2026): > Desired Solution you'd like > Introduce a scoped RBAC model with workspace-level administration. > > Proposed roles: > Global Admin > > Full access across all workspaces (current behavior) > Workspace Admin (NEW) > > Scoped to one or more workspaces > Can: > create/manage Knowledge Bases, Skills (maybe even tools?) if permission given by the Global Admin > manage files within the workspace/KB > optionally configure new CUSTOM models (visibility, defaults) if permission given by the Global Admin > manage users/groups within the workspace > Cannot: > access other workspaces > view global data outside their scope There is no user management within the workspace You can already create a user group, give that user group access to the workspace, and have these users create and manage knowledge bases, set the knowledge bases to public (or only give access to certain groups), and then normal users without access to the workspace area can use the knowledge bases. Literally all of this is already possible with today's permission system

GiteaMirror commented

2026-05-05 23:47:58 -05:00

@giovanisp commented on GitHub (Apr 15, 2026):

@Classic298 hi, sorry, why is that closed? I am using v0.8.12 currently. Is that something already available ?

@giovanisp commented on GitHub (Apr 15, 2026): @Classic298 hi, sorry, why is that closed? I am using v0.8.12 currently. Is that something already available ?

GiteaMirror commented

2026-05-05 23:48:00 -05:00

@Classic298 commented on GitHub (Apr 15, 2026):

Yes. As i replied above everything you described is literally already there please read the docs

@Classic298 commented on GitHub (Apr 15, 2026): Yes. As i replied above everything you described is literally already there please read the docs

GiteaMirror commented

2026-05-05 23:48:02 -05:00

@giovanisp commented on GitHub (Apr 15, 2026):

@Classic298 thanks for the clarification but I think I didn’t explain the use case correctly. What you describe is partially achievable only if users are granted "Admin" privileges right? Unfortunately this is exactly what we cannot do in our enterprise setup.

You are right that user groups can be assingned to workspaces and can manage Knowledge Bases within a workspace however the key limitation is that Workspace creation and full management capabilities are restricted to Admin users, and Admins have global visibility across all workspaces.

My actual setup is:

Authentication via Microsoft Entra ID (SSO)
Workspaces mapped 1:1 to Entra ID groups
Each group represents a team/project
Our Enterprise requirement: strict isolation between teams

My proposal was then to allow regular "non-admin" single users to:

create and manage their own workspace
manage KBs, files, skills/tools and models within that workspace
manage access (groups/invite other users) within that workspace

But without granting them a global Admin role thus exposing other workspaces data to them. To fully manage workspaces requires central admin for every operation and that is not scalable.

A new scoped role for Workspace Admin would solve this problem in larger companies (i.e: a user could create a workspace and automatically become its scoped admin and invite other company users without any global data violation).

That distinction is the core of this feature request. What do you think ?

@giovanisp commented on GitHub (Apr 15, 2026): @Classic298 thanks for the clarification but I think I didn’t explain the use case correctly. What you describe is partially achievable only **if users are granted "Admin" privileges** right? Unfortunately this is exactly what we cannot do in our enterprise setup. You are right that user groups can be assingned to workspaces and can manage Knowledge Bases within a workspace however the key limitation is that Workspace creation and full management capabilities are restricted to Admin users, and Admins have global visibility across all workspaces. My actual setup is: - Authentication via **Microsoft Entra ID (SSO)** - Workspaces mapped 1:1 to **Entra ID groups** - Each group represents a team/project - Our Enterprise requirement: **strict isolation between teams** My proposal was then to allow regular "non-admin" single users to: - create and manage **their own workspace** - manage KBs, files, skills/tools and models **within that workspace** - manage access (groups/invite other users) **within that workspace** But **without** granting them a global Admin role thus exposing other workspaces data to them. To fully manage workspaces requires central admin for every operation and that is not scalable. A new scoped role for Workspace Admin would solve this problem in larger companies (i.e: a user could create a workspace and automatically become its scoped admin and invite other company users without any global data violation). That distinction is the core of this feature request. What do you think ?

GiteaMirror commented

2026-05-05 23:48:05 -05:00

@Classic298 commented on GitHub (Apr 15, 2026):

@giovanisp please. Please read the docs.

There is no such thing as "creating a workspace" in Open WebUI. The Workspace is just a UI section — it's not a container you spin up.

Multi-tenancy is done through Groups as i already said above. With ENABLE_OAUTH_GROUP_MANAGEMENT and ENABLE_OAUTH_GROUP_CREATION, your Entra ID groups auto-sync.

Members of groups create resources, share them with their group, done.

Set BYPASS_ADMIN_ACCESS_CONTROL=false if you don't want admins seeing everything.

That's the architecture. What you're describing is already fully possible in it's entirety

Please read the docs

Please

@Classic298 commented on GitHub (Apr 15, 2026): @giovanisp please. Please read the docs. There is no such thing as "creating a workspace" in Open WebUI. The Workspace is just a UI section — it's not a container you spin up. Multi-tenancy is done through **Groups** as i already said above. With `ENABLE_OAUTH_GROUP_MANAGEMENT` and `ENABLE_OAUTH_GROUP_CREATION`, your Entra ID groups auto-sync. Members of groups create resources, share them with their group, done. Set `BYPASS_ADMIN_ACCESS_CONTROL=false` if you don't want admins seeing everything. That's the architecture. <ins>**What you're describing is already fully possible in it's entirety**</ins> Please read the docs Please

GiteaMirror commented

2026-05-05 23:48:06 -05:00

@giovanisp commented on GitHub (Apr 15, 2026):

alright.. let me go through the docs again and test my setup with BYPASS_ADMIN_ACCESS_CONTROL=false (the other settings are already in place). I’m very curious to see if I can get my users to create and manage their own tools/skills, knowledge bases, and models while not seeing resources created by other teams (groups). I initially assumed that a model with Global Admin + Workspaces would cover this use case, so I’ll re-evaluate my settings. Thanks again for the support.

@giovanisp commented on GitHub (Apr 15, 2026): alright.. let me go through the docs again and test my setup with `BYPASS_ADMIN_ACCESS_CONTROL=false` (the other settings are already in place). I’m very curious to see if I can get my users to create and manage their own tools/skills, knowledge bases, and models while not seeing resources created by other teams (groups). I initially assumed that a model with Global Admin + Workspaces would cover this use case, so I’ll re-evaluate my settings. Thanks again for the support.

GiteaMirror commented

2026-05-05 23:48:07 -05:00

@icsy7867 commented on GitHub (May 5, 2026):

Did you figure this out? I might be overcomplicating this? In the group permissions, it seems I can give someone access to knowledge access and knowledge sharing but it seems to be an all or nothing? Am I reading that correctly?

@icsy7867 commented on GitHub (May 5, 2026): Did you figure this out? I might be overcomplicating this? In the group permissions, it seems I can give someone access to knowledge access and knowledge sharing but it seems to be an all or nothing? Am I reading that correctly?

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#58729