cloudflare/authr

此包最新版本(v3.0.1)没有可用的许可证信息。

一个灵活、表达性强、语言无关的访问控制框架

v3.0.1 2020-11-27 15:30 UTC

README

GO Build Status JS Build Status PHP Build Status

一个灵活、表达性强、语言无关的访问控制框架。

工作原理

authr是一个访问控制框架。将其描述为“框架”是有意的,因为它是现成的,不会自动开始保护您的应用程序。它对很多事情都非常“无关紧要”。它代表了一组构建块,可以编排和组合起来,以支撑一个访问控制系统。由于其基本性,它可以满足几乎任何在特定系统中控制对特定资源访问的需求。

词汇表

该框架本身具有与ABAC访问控制系统的类似词汇。以下解释了关键术语。

主题

在此框架中,主题代表一个能够执行动作的实体;可以将其称为行为者。在大多数情况下,这将是“用户”或“管理员”。

资源

资源代表一个可以被作用的实体。在博客应用中,这可能是“文章”或“评论”。这些是可以被希望“编辑”或“删除”它们的主题作用的实体。值得注意的是,主题也可以是资源——一个“用户”可以执行动作并且可以被作用。

资源具有authr可以分析的属性。例如,一个post可能有一个属性id,值为333。或者,一个用户可能有一个属性email,值为person@awesome.blog

动作

动作是对正在尝试的动作的简单、简洁的描述。如果某个“用户”试图修复其“文章”中的错误,那么动作可能是edit

规则

规则是一个条件语句,它组合了对资源和动作的条件,并指定是否允许或拒绝匹配规则时的尝试。例如,如果您想“允许”主题编辑一个私有文章,则规则的JSON表示可能如下所示

{
  "access": "allow",
  "where": {
    "action": "edit",
    "rsrc_type": "post",
    "rsrc_match": [["@type", "=", "private"]]
  }
}

注意,没有指定对实际执行动作的条件。这很重要;稍后将有更多介绍。

通过接口的无偏见性

在实现中,authr要求对象实现某些功能,以便其引擎可以正确分析资源与属于主题的规则列表。

一旦应用程序中的基本对象实现了这些接口,就可以最终提出基本问题:这个主题是否可以在这个资源上执行这个动作?

<?php

use Cloudflare\Authr;

class UserController extends Controller
{
    /** @var \Cloudflare\AuthrInterface */
    private $authr;
    ...

    public function update(Request $req, Response $res, array $args)
    {
        // get the subject
        $subject = $req->getActor();

        // get the resource
        $resource = $this->getUser($args['id']);

        // check permissions!
        if (!$this->authr->can($subject, 'update', $resource)) {
            throw new HTTPException\Forbidden('Permission denied!');
        }

        ...
    }
}

形成主题

authr通常是可识别为ABAC框架的。它依赖于在资源属性上放置某些条件的能力。然而,有一个关键区别:规则语句中无法指定对主题的条件。

代替,唯一指定特定行为者能够在资源上执行动作的方法是从返回的规则列表中发出一个匹配动作并允许其发生的规则。因此,主题永远只作为一个规则列表而知名。

type Subject interface {
    GetRules() ([]*Rule, error)
}

规则不再是静态定义在某个地方,需要框架担心从哪里获取规则,相反,规则属于主题,并且始终从主题中检索。

当检查权限时,框架将简单地通过主题的接口调用一个方法来检索特定主题的规则列表。然后,它会遍历该列表,直到匹配到一条规则,并根据规则想要允许或拒绝来返回一个布尔值。

为什么不允许检查行动者的属性?

通过将行动者简化为只是一系列规则,它将关于主题能够做什么的逻辑压缩到一个区域,并阻止它在应用程序的代码库中分散。

此外,在传统的RBAC访问控制系统中,检查特定行动者是否在某个“角色”中或检查行动者的ID以确定访问是非常脆弱的,并且会使代码库“老化”。

通过有一个负责回答访问控制问题的单个组件,并结合强制清晰地表达行动者可以使用authr规则做什么,这导致了极好的关注点分离,并使代码库更加可持续。

即使authr不是你选择的访问控制,以这种方式组织服务中的访问控制也有明显的优势,并且authr确保事情保持这种状态。

在服务边界之间表达权限

因为authr中的权限基本单元是一个定义在JSON中的规则,所以可以让其他服务为自己的目的执行访问控制检查。

在Cloudflare内部的例子是,在一个管理服务中。通过将此权限定义为JSON,我们可以简单地将所有规则传输到前端(在JavaScript中),并允许前端根据登录者的权限隐藏/显示某些功能。

当你可以通过只更新一次单条规则,使前端和后端在访问控制上无缝地达成一致时,可以大大提高可维护性。

待办事项

  • 创建集成测试,确保实现之间达成一致
  • 完成Go实现
  • 添加使用authr进行访问控制的完整应用程序示例
  • 添加关于规则格式的文档