认证与授权
本文旨在为开发您自己的身份验证和授权工作流提供一个连贯的最佳实践指南。
有关以下涉及的各个操作的详细说明,请参阅另请参阅中的链接。
真实企业场景
大型企业通常具有复杂的组织结构和大量使用各种平台和工具的员工。从 IT 治理的角度来看,拥有统一的身份、身份验证和授权系统带来了显著的优势:
- 简化的用户管理:管理员不再需要在多个系统中手动创建或删除用户并分配权限。用户生命周期管理(例如,入职/离职)变得无缝且易于审计。
- 提高的安全性:单点登录(Single Sign-on, SSO)机制消除了用户管理多个凭据的需求,减少了攻击面。
- 角色对齐的访问控制:访问权限通常与用户的角色或部门相关联。结构良好的身份系统可以更轻松、更准确地进行授权决策。
示例
假设有三名新员工加入一家 SaaS 公司的不同部门:一名市场专员和两名解决方案架构师。
- 组织上,他们属于不同的团队。
- 从身份角度,他们的电子邮件帐户作为其在内部平台上的登录凭据。
- 按 访问权限,三人分别被授予不同平台的访问权限:
- 市场专员可以登录 Hubspot 后台查看新线索。
- 解决方案架构师可以访问服务控制台,并为指定客户管理服务。
尽管三人使用相同的身份提供者,但其访问权限受到严格执行:
- 市场专员仅能访问 Hubspot。
- 解决方案架构师可以访问服务控制台,但不能访问未分配给他们的用户的服务,也不能访问 Hubspot。
三层访问控制
此示例突出了企业身份和访问流程中的三个关键组件:
- 身份验证 – “我是彼得,一名经过验证的 SaaS 公司员工。”
- 访问验证 – “作为解决方案架构师,我被授权登录服务控制台。”(并非所有经过验证的员工都应访问所有服务。)
- 操作授权 – “作为 SaaS 公司的客户,我可以查看我们自己的服务信息,但不能查看其他客户的。”
基于数据库背景
这些访问控制层也适用于数据库系统:
- 身份验证:确认用户是有效员工,并拥有自己的密码。
- 访问验证:验证用户或其组是否有权限登录特定集群。
- 操作授权:检查用户是否可以运行查询 、导入数据等。
如您所见,身份验证和授权在实践中是紧密结合的。用户的身份验证请求通常意味着更广泛的访问控制要求。因此,了解完整的访问流程至关重要。
关键概念
LDAP
轻量级目录访问协议(Lightweight Directory Access Protocol,LDAP)是一种用于访问和维护分布式目录信息的协议。您可以将其视为组织的全局地址簿:
- 每个用户都有一个唯一的路径(专有名称,DN)。
- LDAP 存储基本的用户信息,包括密码。
- LDAP 还管理组结构和成员关系。
ldapsearch查询可以检索用户或组。
LDAP 可以用作:
- 身份验证来源(验证用户名和密码)。
- 用于访问控制的组信息提供者。
UNIX Groups
出于安全或隔离的原因,有时用户会在本地(主机操作系统上)镜像 LDAP 组,以避免与外部 LDAP 服务器直接通信。这些本地 UNIX 组可用于身份验证或访问控制执行。
OAuth、OIDC 和 JWT
提示
术语解释
- ID Token: 身份证明(我是我。)
- Access Token: 访问某些资源的权限证明(我可以做某些事情。)
- OAuth 2.0: 提供访问令牌的授权框架。
- OIDC: OAuth 之上的身份验证层。提供 ID 和访问令牌。
- JWT: 令牌格式。同时被 OAuth 和 OIDC 使用。
实际应用:
- 基于 OAuth 的登录:重定向到外部登录页面(例如,Google),然后返回集群。需要提前设置浏览器访问和重定向 URL。
- 基于 JWT 的登录:用户直接将令牌传递给集群,这需要提前设置公钥或端点。
功能
系统支持所有三层访问控制:
- 用户身份验证 – “我就是我所说的那个人。”
- 登录授权 – “我被允许访问此集群。”(这取决于个人或组成员身份。)
- 操作授权 – “我可以运行此查询或导入此数据集。”(授权可以基于身份或组关系。)
从 v3.5 开始,StarRocks 提供了一个模块化、可组合的模型,以支持各种身份和访问管理组件的结合。
功能映射

从功能的角度来看:
- 身份验证提供者 – 支持的协议:本地用户、LDAP、OIDC 和 OAuth 2.0。
- Group Provider – 支持的来源:LDAP、操作系统和基于文件的配置。
- 授权系统 – 支持的系统:内置 RBAC & IBAC 和 Apache Ranger。
身份验证
支持的身份验证模式比较:
| 方法 | CREATE USER(本地用户) | CREATE SECURITY INTEGRATION(基于会话的虚拟用户) |
|---|---|---|
| 描述 | 在集群中手动创建用户,可与外部认证系统关联。该用户在集群中以显式方式存在。 | 定义一个外部认证集成。集群本身不保存任何用户信息。可选地结合 Group Provider 使用,用于定义允许访问的用户组。 |
| 登录过程 | 用户必须事先在集群中创建。在登录时,StarRocks 会通过自身或配置的外部认证系统(如 LDAP)对用户进行认证。只有预先创建的用户才能登录。 | 用户登录时,StarRocks 通过外部身份认证系统验证用户身份。若 验证成功,系统会在内部创建一个临时的、会话级别的“虚拟用户”,该用户在会话结束后即被销毁。 |
| 授权过程 | 因为用户在集群中是持久存在的,所以可以提前通过本地授权系统或 Apache Ranger 为其分配权限。 | 虽然用户不会在集群中持久化,但可以预先定义角色与用户组之间的映射关系。用户登录后,系统会根据其所属用户组自动分配角色,从而实现基于角色的访问控制(RBAC)。Apache Ranger 也可同时使用。 |
| 优缺点及适用场景 |
|
|
这些身份验证模式可以共存。当用户尝试登录时:
- 集群首先检查用户是否为本地用户,并尝试相应地进行身份验证。
- 如果未找到用户,集群将按照配置中定义的
authentication_chain继续进行。
这种混合模式提供了灵活性和控制力,适合不同的组织需求。