用户权限的设计

背景

今天聊聊用户权限的设计思路.
一般来说,只要系统中存在用户,就会有权限.
而在权限设计中一般会有数据权限和功能权限之分.
我们该怎么设计我们系统的权限呢?

设计

在设计权限之前,我们先要想想有哪些模型?
我所理解的模型有如下这些:

• resource(资源)
• user(用户)
• action(资源操作)
• role(角色)

说白了,权限要解决的问题就是判断是否允许某个用户对某个资源做某个操作
虽然听起来有点拗口.不过没关系,多读几遍就顺口了.O(∩_∩)O
问题来了,这个模型该怎么组合才能达到我们想要的效果呢,先来看张图:

我把上面的这些模型在图中标注了颜色.那怎么来看上面这张图呢?
我用下面的几条建议(或者叫原则)来说明.

都是API

不管是外部系统的调用,还是在web上做操作都必须用API的方式来实现
这是权限设计的基础,这个API的范围比较广,举个例子:

• 修改一个配置项
• 查看一个表格形式的数据
• 增加一个用户
• 给用户赋权
• 删除一个用户

所有这些操作都需要用API来定义.规划API其实就是对resource定义action的过程.
这个过程非常重要,这个过程是否顺畅能直接体现出来你的系统设计的时候对领域模型的规划是否合理.
还有一点,在规划API的时候最好设计一个全局的统一入口,这样有利于扩展和维护.

都是User

这个User不一定是一个人,可能也是一个API的accessKey,也可能是一个用户组.

角色很重要

所有对用户赋权都要通过角色来实现.不能user直接和action关联.
上图有个两个比较难理解的东西就是R-Resource-User-Role和R-User-Role
R-Resource-User-Role:用于实现数据权限,表示某个用户在某个资源上是什么角色,比如奥巴马(用户)是美国(资源)的总统(角色)
R-User-Role:用于实现功能权限,表示某个用户是什么角色,比如奥巴马(用户)是个男人(角色)

结束语

通过上面这个模型基本能设计一个比较灵活的权限系统.从上面可以看出来基本没有新的名词或者模型.
有的只是对现有模型的做了更进一步的抽象.