简体中文

ciam
auth
authorization

CIAM 102：授权与基于角色的访问控制

组织和租户非常适于对身份进行分组，但它们导致了一种绝对的民主：在这个系统中，每个人都可以做任何事情。虽然乌托邦仍然是一个谜，让我们看一下访问的治理：授权（AuthZ）。

Gao

Founder

2/5/2023

不要在用户认证上浪费数周时间

使用 Logto 更快地发布安全应用。几分钟内集成用户认证，专注于您的核心产品。

立即开始

背景

在前一篇文章中，我们介绍了认证（AuthN）和授权（AuthZ）的概念，以及一些令人头痛的术语：身份，组织，租户等。

组织和租户非常适合对身份进行分组，但它们通向绝对的民主：在这个系统中，每个人都可以做任何事情。虽然乌托邦仍是一个谜，让我们看一下访问的治理：授权（AuthZ）。

为什么我们需要授权？

Notion 是一个很好的例子。对于你拥有的每一个页面，你可以选择让它私有，只有你可以访问，或者与朋友分享，甚至公开。

或者，对于一个在线书店，你希望每个人都能看到所有的书，但是客户只看他们自己的订单，和卖家只管理他们商店里的书。

AuthZ 和 AuthN 是复杂业务模型的必要组成部分。它们通常并肩作战；AuthZ 验证用户的访问，而 AuthN 对身份进行认证。两者对于一个安全的系统都是必要的。

基本的授权模型

这是最常见的 AuthZ 模型之一：如果身份对资源执行动作，那么接受或被拒。

在 Notion 的例子中，模型是个人对页面执行查看。

如果页面是私有的：

当你对你的页面执行查看时，你将收到接受。
所有其他人当对你的页面执行查看时，应该收到被拒。

基于共识，业界开发了各种授权技术，如基于角色的访问控制（RBAC），基于属性的访问控制（ABAC）。今天，我们将关注NIST RBAC 模型级别1：Flat RBAC。

基于角色的访问控制

让我们扩展书店的例子。假设我们有很多客户，但只有一个卖家：

客户可以查看和订购书籍，以及查看他们自己的订单。
卖家可以查看，创建和删除书籍，并管理客户订单。

定义资源

在 Logto 中，资源（即 API 资源）通常代表一组实体或项目，因为需要使用有效的 URL 作为指示器。因此我们定义了两个资源：

书籍：https://api.bookstore.io/books
订单：https://api.bookstore.io/orders

强制使用 URL 格式的一个优点是它可以映射到你 API 服务的实际地址，当与系统中的其他组件集成时，可以提高可读性和可识别性。

定义权限

由于我们引入了资源的概念，在 Logto 中，我们还强制要求权限必须属于资源，反之，资源可以拥有权限。

让我们为资源添加一些权限：

书籍：read，create，delete
订单：read，read:self，create:self，delete

尽管没有权限名称的要求，我们有以下约定：

<action> 要求描述一个权限，:<target> 可以忽略描述一个通用目标，即对资源中的所有实体或项目。例如：

书籍资源中的权限 read 表示读取任意书籍的动作。
订单资源中的权限 create:self 表示创建属于当前用户的订单的动作。

定义角色

简单来说，一个角色就是一组权限。让我们创建两个角色 customer 和 seller 并把权限分配给它们如下：

你可能注意到，权限和角色的赋予是多对多的关系。

把角色分配给用户

就像角色权限赋值一样，用户角色赋值也是一种多对多的关系。因此，你可以把多个角色分配给一个用户，一个角色可以分配给多个用户。

连接各个点

下面是 Logto 中的级别1 RBAC 模型的完整关系图：

在 RBAC 模型中，权限总是 "positive" ，意味着授权判断很简单：如果用户有权限，那么接受；否则，拒绝。

假设 Alice 有 seller 角色，Bob 和 Carol 有 customer 角色。我们首先用自然语言描述动作，然后把它们编译到标准的授权格式：IDENTITY performs ACTION on RESOURCE，最后给出结论。

Alice 想添加一本新书出售：
- 用户 Alice 对资源 Books （https://api.bookstore.io/books）执行 create。
- 由于 Alice 根据他们的 seller 角色被赋予了 Books 的 create 权限，结果是 ✅ 接受。
Alice 想查看所有订单以看看销售是否符合他们的期望：
- 用户 Alice 在 Orders 资源（https://api.bookstore.io/orders）上执行 read。
- 由于 Alice 根据他们的 seller 角色被赋予了 Orders 的 read 权限，结果是 ✅ 接受。
Bob 想浏览书籍列表，看看有没有他们想购买的书。
- 用户 Bob 在 Books 资源（https://api.bookstore.io/books）上执行 read。
- 由于 Bob 根据他们的 custome 角色被赋予了 Books 的 read 权限，结果是 ✅ 接受。
Bob 想查看 Carol 的订单。
- 由于这是别人的订单，所以 Orders 的 read:self 权限在此不起作用。
- 用户 Bob 对 Orders 资源（https://api.bookstore.io/order）执行 read。
- 由于 Bob 没有 Orders 的 read 权限，结果是 ❌ 拒绝。

其他 RBAC 等级

NIST RBAC 模型有四个级别：

Flat RBAC
Hierarchical RBAC
Constrained RBAC
Symmetric RBAC

如果你对此感兴趣，可以查看论文获取详细信息。

Logto 现在有 Level 1 的实现，将根据社区反馈进行更高级别的进展。如果更高级别适合你的需求，不要犹豫，告诉我们！

实践中

除了理论，我们还有大量技术工作要完成，以期模型能按预期工作：

客户端和 auth 服务器开发
RBAC 数据库设计
在不同服务之间的验证
安全和开放标准合规
角色，权限，资源管理和赋值

不要恐慌。我们考虑到这一点，并为所有上述内容增加了开箱即用的支持。查看 🔐 RBAC 菜谱，学习如何在 Logto 中使用 RBAC。

结束语

RBAC 对于大部分情况是一个强大的访问管理模型，但没有银弹。我们仍然有一些问题：

我需要高级别的 RBAC 吗？
RBAC 与其他授权模型相比如何？
如何定义不同组织之间的授权模型？

背景#

为什么我们需要授权？#

基本的授权模型#

基于角色的访问控制#

定义资源#

定义权限#

定义角色#

把角色分配给用户#

连接各个点#

其他 RBAC 等级#

实践中#

结束语#

背景#

为什么我们需要授权？#

基本的授权模型#

基于角色的访问控制#

定义资源#

定义权限#

定义角色#

把角色分配给用户#

连接各个点#

其他 RBAC 等级#

实践中#

结束语#

背景

为什么我们需要授权？

基本的授权模型

基于角色的访问控制

定义资源

定义权限

定义角色

把角色分配给用户

连接各个点

其他 RBAC 等级

实践中

结束语

背景

为什么我们需要授权？

基本的授权模型

基于角色的访问控制

定义资源

定义权限

定义角色

把角色分配给用户

连接各个点

其他 RBAC 等级

实践中

结束语