🔐 认证与访问控制
控制谁能进入系统、能做什么，以及你的实例如何接入现有身份体系。
OPL 数据空间从第一天起就是多用户系统。无论你是在运行个人实例，还是在多个组织中管理成千上万席位，你都可以控制认证、授权、审查访问和程序化访问能力。接入你的身份提供方，定义细粒度权限，并自动化用户生命周期，而不必重造整套身份系统。
本节内容
| 👥 RBAC | 角色、用户组和按资源划分的权限，定义谁能访问什么 |
| 🔑 SSO / OIDC | 与 Google、Microsoft、Okta、Keycloak 或任意 OIDC 提供方做联合认证 |
| 📂 LDAP | 对接现有目录服务完成认证 |
| 📋 SCIM 2.0 | 从 IdP 自动开通与回收用户、用户组 |
| 🔐 API Keys | 面向脚本、机器人、pipeline 和外部集成的程序化访问 |
它们如何协同
- 用户先完成认证，方式可以是 SSO、OIDC、LDAP 或本地账号密码。
- SCIM 自动下发 用户和用户组。
- RBAC 决定访问权限，依据包括全局角色、组织内能力和用户组成员关系。
- 权限是叠加的：每个用户组只会增加能力，不会删除已有能力。
- API Keys 会继承创建者当前的有效权限和当前作用域，用于程序化访问。
SSO-only 场景
在纯 SSO 环境中，你可以通过 ENABLE_PASSWORD_AUTH=false 禁用本地密码登录，再通过 ENABLE_PASSWORD_CHANGE_FORM=false 隐藏账户页中的密码修改入口。
快速开始
个人或小团队：先从简单模式开始
OPL 数据空间开箱即用就支持本地邮箱/密码认证，不需要外部身份提供方。创建账号，分配 admin 或 user 角色即可。
组织化部署：叠加 SSO 与 SCIM
- 配置 SSO：接入身份提供方
- 配置 RBAC：创建用户组，分配权限和 ACL
- 启用 SCIM（可选）：自动化用户生命周期
- 生成 API Keys（可选）：为自动化流程开放程序化访问
关键概念
叠加式权限
OPL 数据空间的安全模型是叠加式的。用户先获得角色自带的默认权限，用户组成员关系只会继续增加能力。最终生效权限是角色与全部用户组授权的并集。
按资源划分的访问控制
模型、知识库、工具和 Skills 都支持细粒度访问控制。资源默认是私有的，资源创建者可以通过用户授权、用户组授权或公开可见性来控制谁能访问。
管理员与普通用户不再只是二元对立
现代部署通常需要比“admin vs user”更丰富的模型：
- 管理员：保留平台级控制权
- 经理：可拥有运营可见性，但不一定具备全部设置权限
- 审计员：可查看聊天和频道历史，但不等于完整管理员
- 普通用户：依照授予权限使用系统
- Pending：激活前保持阻塞状态
组织还再叠加一层：组织管理员 不是单独的全局角色，而是一个可以由全局管理员为某个租户委派的组织级管理能力。
组织与身份体系
启用组织后：
- 每个用户都属于一个归属组织
- 注册与 SSO 流程都需要落地组织
- SCIM 与用户开通工作流要按租户边界来设计
- API Key 应被视作“代表创建它的用户”，而不是绕过组织边界的万能密钥