本文作者：[wangwenhai] # 概要：概要->在认真分析了传统Rolebase设计西路以后，和Restful风格接口进行对比，提炼了一些通用的思路和不同的思路，设计了一套权限管理系统。

RestFul风格权限系统设计

1.背景

近期在做物联网管理平台，准备采用传统的RBAC设计思路，但是目前的后端接口我们按照严格的Restful风格来设计，因此传统的Rolebase（角色为主）的设计方法此时就出现了弊端。在认真分析了传统Rolebase设计西路以后，和Restful风格接口进行对比，提炼了一些通用的思路和不同的思路，设计了一套权限管理系统。

2.Restful

关于Restful其实网上资料很多，主要就是面向资源的接口形式，通过HTTP语义化形式来提供API接口服务，和传统的接口设计稍有不同：

案例：实现增加、删除、修改、查询博客（表名为Blog）的功能。

我们先用传统的形式来实现：

接口名	HTTP方法	路径
增加	POST	http://://blog/addBlog
删除	DELETE	http://://blog/deleteBlog
修改	UPDATE	http://://blog/updateBlog
查询	GET	http://://blog/queryBlog?title=”XXX”…..

上面给出的是传统写法，一个博客的CURD对应了4个接口地址,这样做的好处是方便了后端开发人员的代码定位，还有业务特点，看见接口就知道是什么含义，有助于理解业务流程。

接下来用Restful形式来实现：

接口名	HTTP方法	路径
增加	POST	http://://blogs
删除	DELETE	http://://blogs
修改	UPDATE	http://://blogs
查询	GET	http://://blogs

你会发现其实都是同一个接口，也就是说针对一个确定的资源，就一个统一入口，我们根据HTTP协议的语义来做业务区分：POST就是创建资源，DELETE就是删除······；都是一一对应的关系。

3.权限系统

如果我们现在要实现一套权限管理系统，针对传统接口风格，我们拟采用Rolebase的设计思路来实现权限控制。

假设系统有A，B两个用户，A的身份是管理员，拥有所有的CURD权限，但是B是一个新用户，只有看博客的权限，即查询权限，我们针对这个场景来设计个模式。

系统角色：ADMIN，USER，其中ADMIN的权限是CURD，USER的权限是R，见下表：

角色	权限
ADMIN	新建
更新
删除
查询
USER	查询

其中给A用户ADMIN的角色，B用户USER角色，到这一步就设计好了，角色对应的权限不同，从而实现了资源隔离。

目前比较流行的框架，比如Shiro，SpringSecurity都是这种形式，这种做法在WEB系统开发中很常见。

接下来我们分析一下这样做的弊端：

1 .每个功能对应一个接口，浪费接口数量；

2 .系统的角色控制是确定的，比如：/blog/addUser的权限就是ADMIN，后端比如明确指定角色，比如Shiro用了@RequireRole注解来标记。假如说用户的角色和权限是动态的，此时我就要USER来访问/blog/addUser，这时怎么办？貌似只能去改源码。因此这样不适合灵活变动的角色行为；

为了应变灵活的角色权限变动，我们设计了一套基于Restful风格的权限机制。

Restful风格建议面向资源，因此我们设计的一个接口有多个功能，区分是HTTP的Method，所以传统的做法到Method的时候就拦截不了。我们做了如下设计：

权限格式：

格式解释：

·user permissions method:用户在resource的允许的方法权限；

·Resource：资源路径；

·allow method：该资源要求的的权限。

我们来描述一个“管理员可以创建删除blog”的权限可以如下：

表示：/blog下的资源允许的HTTP请求有POST,DELETE,GET,PUT，但是管理员只能POST和DELETE。

我们如何去处理权限？当用户请求过来的时候，我们做一个拦截，首先提取出用户的权限列表，然后进行检查对比。具体的检查步骤如下：

1 .提取资源路径R；

2 .提取用户在此处的权限P;

3 .提取资源R的权限S；

4 .做对比：P是否是R的权限的完全子集，也就是说P的每一个Method都必须在S里面存在。伪代码如下：

4.表设计

表结构继续按照USER-ROLE-PERMISSION形式，形成三级关联：

下面看下权限表的内容：

methods表示资源的允许方法。

而role和权限的关联表则记录了用户的资源权限，allow表示用户的权限。

5.后端拦截器设计

拦截器先对请求进行拦截，然后解析出当前请求的资源路径，查看当前用户的权限和资源的权限，做一个全子集判断，流程图如下：

目标资源R：/blog

用户权限U：[GET]

资源权限S：[GET,POST,DELETE,PUT]

简单用伪代码描述一下：