基于Casbin的ABAC授权模型设计与开发踩坑实录

本文分享自天翼云开发者社区《基于Casbin的ABAC授权模型设计与开发踩坑实录》，作者：upclose 最近因项⽬需求，需要寻求⼀个好⽤强⼤的权限管理⽅案。天翼云安全实验室经过仔细调研，最终选择了ABAC（Attribute Based Access Control，基于标签的访问控制）作为授权模型的基础，在具体实现上则青睐于后起之秀Casbin。 ABAC被称为“下一代”授权模型，具有更细粒度的权限设定、更灵活的权限管理等优势。 Casbin是一个开源的权限管理框架，其主要优势有： 支持多种权限模型如ACL、RBAC、ABAC等； 支持多种语言，以Golang为主，同时支持java、PHP等； 活跃的社区和持续更新，这对于开源软件来说是很可贵的品质； 功能强大，上手也不复杂。 下面是一篇基于Casbin实现ABAC授权模型的避坑指南，负重前行只为你的岁月安好。 一、授权模型 虽然开篇就明确了使用ABAC，不过在此还是要多言两句，对历来经典授权模型进行一些介绍，也好说明为什么最终选择了使用ABAC。 二、ACL（Access Control Lists，访问控制列表） 用户A可以访问代码仓库。 所谓表，就形成了一一对应的关系，谁可以访问什么资源，都清楚列在表上。 ACL的优点是容易理解与实现。 ACL的缺点是需要维护的数据庞大，对于m个用户和n个资源，就会产生m*n的访问控制表。 三、RBAC（Role Based Access Control，基于角色的访问控制） 开发人员可以访问代码仓库。 RBAC之于ACL的一大改进，在于把用户聚类成了角色，而以角色的粒度进行权限管理。 RBAC的优点包括了ACL的优点，同时大幅度减小了需要维护的权限数据表。 RBAC的缺点则是缺乏灵活性，因为角色是管理用户最小粒度。 四、ABAC（Attribute Based Access Control，基于标签的访问控制） 9am-6pm之间可以访问代码仓库。 有了ACL和RBAC的前车之鉴，ABAC是在灵活性上下了功夫，提出基于标签进行授权管理，从而给授权管理这一历史性课题带来了动态性。相比与ACL中小明可以访问资源，以及RBAC中开发人员可以访问资源，ABAC中采用了上班时间在办公网络中可以访问资源的说法，而时间和网络环境则成为ABAC中作为授权决策的关键因素，即标签。 ABAC的优点是灵活性极大，不在拘泥于特定的对象，而是把审时度势的思考带入到的权限管理中；不再维护巨大的角色-资源对应表也是其一大优势。 ABAC的缺点在于门槛较高，因为标签这一概念并不直观，维护工作也往往需要专门的人员才能进行。 五、PBAC（Policy Based Access Control，基于策略的访问控制） PBAC并不是学院提出的，更像民间的说法，是一种在ABAC的基础上增加策略的授权管理。然而ABAC并不是没有策略，ABAC的标签是需要策略才能执行的。所以笔者认为PBAC只是ABAC的另一种理解方式，而非新的授权模型。 六、PERM描述语言 PERM即Policy, Effect, Request, Matchers，是Casbin中用来描述授权模型的一门语言。基于PERM语言，就可以实现各种授权模型，而PERM也赋予了Casbin在各种传统授权模型上进行自定义改进的能力。 使用Casbin官方提供的在线编辑器可以实时进行PERM编写实验。 PERM中的四大元素含义如下： Request：授权请求，至少需要包含请求者（sub）、请求资源（obj）和请求行为（act）； Policy：授权决策，与授权请求相匹配； Effect：策略影响，决定策略的最终效果； Matcher：授权模型的核心行为，描述了上述几大元素在模型中是如何协作完成授权工作。 Casbin提供了用PERM描述ABAC模型的示例代码： [request_definition] r = sub, obj, act [policy_definition] p = sub_rule, obj, act [policy_effect] e = some(where (p.eft == allow)) [matchers] m = eval(p.sub_rule) && r.obj == p.obj && r.act == p.act 其中matcher最为值得注意，其由3个布尔判断构成。当授权请求到来时，r.obj == p.obj和r.act == p.act用于通过请求的信息（r）查询得到对应的策略（p）。在得到策略之后，eval(p.sub_rule)执行策略中配置的标签条件判断，从而得到最终的授权请求决策结果。 Casbin举例的ABAC策略如下： p, r.sub.Age > 18 && r.sub.Age < 60, /data1, read 该策略在有用户请求对/data1资源进行read操作时生效，通过判断该请求者的Age标签是否在18-60的范围内，从而决策该请求者是否可以对/data1进行访问。 七、Casbin实践 7.1 模型与策略设计 正如上文对ABAC的介绍，用一句话对ABAC的决策进行概括，可以举例为上班时间在办公网络中可以对代码仓库进行访问。其中代码仓库（例如gitlab.xxx.com）是obj，时间和网络环境是标签，分别为sub.Time和sub.IP，而访问行为就是access。 根据PERM的语法，针对代码仓库这一资源的访问策略可以写作： p, r.sub.Time >= 9 && r.sub.Time <= 18 && r.sub.IP == 1.1.1.1, gitlab.xxx.com, access 当然在实际场景中，仅仅通过时间和IP进行访问控制并不灵活，但针对策略进行修改，不需要修改模型，就可以赋予该ABAC授权模型动态的能力，例如增加对用户访问行为的检测、 对授权失败的用户增加二次授权认证的策略等。 7.2 基于Casbin的ABAC模型构建 Casbin目前不支持MongoDB数据库，所以就先用MySQL。在Golang中需要使用xormadapter与数据库进行交互： // 连接MySQL数据库 mysqlString := fmt.Sprintf("%s:%s@tcp(%s:%d)/", mysqlUser, mysqlPassword, mysqlIP, mysqlPort) a, err := xormadapter.NewAdapter("mysql", mysqlString) if err != nil { return errors.New("Connect to database error: " + err.Error()) } Casbin数据库用来存储策略，也可以用来存储模型。不过模型一般不会修改（需要时常修改模型的设计一定有问题），所以模型可以直接硬编码在代码中： // 创建ABAC模型 abacModel := ` [request_definition] r = sub, obj, act [policy_definition] p = sub_rule, obj, act [policy_effect] e = some(where (p.eft == allow)) && !some(where (p.eft == deny)) [matchers] m = r.obj == p.obj && r.act == p.act && eval(p.sub_rule) ` m, _ := model.NewModelFromString(abacModel) 最后拥有了模型和数据库，Casbin就可以跑起来了： // 创建引擎 enforcer, err = casbin.NewEnforcer(m, a) // 加载策略 err = enforcer.LoadPolicy() 还需要添加策略，以上述通过时间和环境进行访问授权决策的策略为例： rule := "r.sub.Time >= 9 && r.sub.Time <= 18 && r.sub.IP == 1.1.1.1" object := "gitlab.xxx.com" action := "access" _, err := enforcer.AddPolicy(rule, object, action) 7.3 ABAC模型授权 在授权请求时需要首先定义请求者即sub，sub的字段名称需要和Policy中的定义一致（包括大小写）： type Subject struct { Time int IP string } 最后在授权请求发生时，调用起Casbin的API对授权请求进行决策，在该过程中，Casbin会从数据库中找找符合的Policy，通过计算Policy中定义的规则，得到决策结果： // 1. 根据授权请求，实例化请求者 sub := Subject{ Time: time.Now().Unix(), IP: ip, } // 2. 调用ABAC引擎，计算用户访问授权结果 ok, _ := enforcer.Enforce(sub, obj, act)