用户组 (Groups)

Open WebUI 中的**用户组 (Groups)**是用于组织用户并进行大规模访问控制的强大机制。它们主要服务于以下两个目的：

1. 权限管理：高效地向多个用户分配细粒度权限。
2. 资源访问控制：控制谁可以访问特定的私有资源（模型、知识库、工具）。

权限合并逻辑

Open WebUI 权限是累加式的（基于并集）。

• 如果一个用户属于多个用户组，他们将获得所有权限的并集。
• 如果 用户组 A 允许“图片生成 (Image Generation)”而 用户组 B 不允许，那么同时属于这两个用户组的用户将拥有图片生成的权限。
• 不存在“拒绝 (Deny)”权限；您只能“授予 (Grant)”权限。

用户组管理

您可以在 Admin Panel > Groups 部分对用户组进行管理。

用户组配置

创建或编辑用户组时，您可以配置其在系统中的可见性：

• 谁可以分享到此组 (Who can share to this group)：（访问控制设置）
  • 任何人 (Anyone)：（默认）平台上的任何用户都可以在分享和共享的“访问控制”菜单中看到该用户组，并将聊天项、模型、Prompt 或知识库分享给它。
  • 成员 (Members)：只有已经是该用户组成员的用户才会在分享的“访问控制”菜单中看到该用户组选项。这是私有团队协作（例如“市场”团队）的理想设置，确保只有团队成员之间才可以共享资源（模型、Prompt、知识库）。
  • 没有人 (No one)：该用户组对非管理员完全从分享菜单中隐藏。这对于专门用于 RBAC 权限分配的技术用户组（例如“高阶用户”组）非常完美，因为这些组不需要内容共享功能。

策略：权限组 vs 共享组

为了保持系统的整洁和易于管理，请考虑使用命名命名规范将您的用户组划分为两个不同的类别：

1. 权限组 (Permission Groups)（例如，前缀为 [Perms]、Role- 或 P-）

   • 用途：专门用于授予功能（例如 [Perms] Image Gen、[Perms] Web Search）。
   • 配置：将“谁可以分享”设置为 没有人 (No one)。
   • 效果：用户获得了他们需要的功能，但这些技术用户组不会使“分享”菜单变得杂乱。

2. 共享组 (Sharing Groups)（例如，前缀为 Team-、Project- 或使用普通名称）

   • 用途：专门用于组织人员（例如 Marketing、Engineering、Team Alpha）以共享资源。
   • 配置：将“谁可以分享”设置为 成员 (Members) 或 任何人 (Anyone)。
   • 最佳实践：在这些组中禁用所有权限。
     • 依赖 全局默认权限（或单独的 权限组）来获取功能使用权。
     • 为什么？ 这可以确保无痛地进行权限撤销。如果您决定全局禁用某项功能（例如“Web 搜索 (Web Search)”），它将立即对所有人生效。如果您的“共享组”启用了“Web 搜索”，由于用户组的 True 状态会覆盖全局的 False，您将不得不手动更新每一个用户组以删除该权限。保持功能组的干净以维持全局控制力。

创建方法

• 手动创建：管理员可以手动创建用户组，并通过 UI 界面添加用户。
• OAuth 同步：如果启用了 ENABLE_OAUTH_GROUP_MANAGEMENT，可以从您的 OAuth 提供商（例如 Keycloak、Azure AD）同步用户组。
  • 自动创建：配合 ENABLE_OAUTH_GROUP_CREATION，本地不存在的用户组将被自动创建。
  • 成员同步：用户会被严格地添加/移出用户组，以与其 OAuth Claim 保持一致。

用户组结构

用户组定义通常包括：

• 名称 (Name)：用户组的显示名称。
• 描述 (Description)：用户组的用途。
• 权限 (Permissions)：一个详细的 JSON 对象，用于覆盖默认用户权限（参见 权限 (Permissions)）。
• 成员 (Members)：属于该用户组的用户 ID 列表。

为用户组分配权限

编辑用户组时，您可以开启或关闭特定的权限。

• 默认状态：默认情况下，用户组不会授予任何额外的权限；成员依赖于全局默认值。
• 授予访问权限：将用户组的某项权限（例如“网页搜索 (Web Search)”）切换为 ON，意味着即使该功能在全局被禁用，所有该组成员也将获得该功能。

资源访问控制 (RBAC)

您可以使用用户组或单个用户授权，来限制对特定对象（如专有模型或敏感知识库）的访问。

1. 标记资源：在创建/编辑模型或知识库时，将其可见性设置为私有 (Private)或受限 (Restricted)。
2. 授予访问权限：选择应该拥有“只读 (Read)”或“读写 (Write)”访问权限的特定用户组或个人用户。重新设计的访问控制 UI 可以轻松地一次性添加多个用户组或用户。

模型的知识库范围限定

除了可见性之外，知识库访问也受模型配置的限制。当模型关联了知识库时，它只能访问这些特定的知识库（而不是所有用户可访问的知识库）。有关详细信息，请参阅 利用原生函数调用限定知识库范围。

访问授权系统

在更深层次上，资源访问是通过存储在数据库中的规范化**访问授权 (Access grants)**进行管理的。每次授权都指定了：

• 资源 (Resource)：资源的类型和 ID（例如特定模型或知识库）。
• 主体 (Principal)：谁接收访问权限 —— 可以是用户组，也可以是个人用户。
• 权限 (Permission)：访问级别 —— read 或 write。

例如，授予 "Marketing" 组对某个模型的只读权限，并授予特定编辑用户对该模型的读写权限，会创建两个独立的授权条目。公开访问由带有通配符 (*) 主体的用户授权表示。

• 只读 (Read)：用户可以查看和使用该资源。
• 读写 (Write)：用户可以更新或删除该资源。