[设计]权限设计的一些想法和思考( 三 ) |美好，一直在身边|程序员|可视化技术|

4、职责划分分为：静态、动态。所谓静态职责划分则是在角色创建之初就已经确定了角色的职责内容。动态职责划分是系统运行过程中对用户已有的角色进行控制，例如：某些角色不能共存在用户身上（互斥）、角色或角色的分配数量限定（控制用量）、角色与角色同时只能激活一个进行使用（时刻唯一）。
引入角色的概念后，实际上这已经是一个比较完整的RBAC的权限设计的模型了。

本文插图
4.数据表的设计思路根据3的结论，实质上已经有了一个基础的表设计的雏形。在这里就有一些值得注意的点。
问：权限表是否有必要存在？
答：这个要结合系统的实际使用场景进行考虑，如果系统中的权限的对象很单一，比如只有页面，或者只有api接口的话，其实权限表可有可无。增加权限表反而会导致初始化项目权限的工作量增加。但是若系统中的权限对象是多个，那么权限表的存在就有了更深层次的意义。在权限对象是多个的情况，权限表的存在就是为了更好更抽象的组合“最小特权”及“责任划分”的操作对象。同时，一旦系统中的操作对象增加了，只需要给权限表增加一个对象表和关系表就可以了。这样易于扩展。
问：api接口和页面实际上是没有关系的，但是在鉴权活动是有关系的，页面若和api没有一点绑定联系的话，服务端接口调用的时候则要么拦截掉所有指定的接口（页面和api接口没绑定的话，则页面的接口调用都不能成功），服务端接口完全不拦截接口，也会不安全，但是api接口和页面功能在表结构层面的绑定会产生运维的大量工作成本，如何更好的设计？
答：在权限如何划分中已经提过了这一点，在表结构中，我们可以增加一张业务模块表和操作表（也可以在数据字典表中增加这两类数据），我们可以在页面和功能点钟绑定业务模块和操作表关系，在api接口的代码层面去绑定业务模块和操作，在逻辑上绑定关系，解耦表结构之间的关系，那么可以在一定程度上解决这一点，这样做只会出现一种问题，那就是用户访问页面的时候可调用的api接口会比实际可调用的接口数要多，但是前端权限管理会隐藏功能点，这样就在可视化的程度上解决了这个问题。
5.安全框架由于我们是基于RBAC的权限设计，现行java框架下最常见的就是shiro和Spring Security。这两个就是仁者见仁智者见智了，我两者都实用过。仅建议使用shiro的话，可以更好的理解RBAC的设计思路， Spring Security 也是个不错的框架，但是它涉及到的概念太多，并不利于初学者去了解最基本的权限设计。我在这只在学习的角度上去比较这两个框架，并没有再其他领域去做比较，也不去比较。
对了，在这里说一下，我目前是在职Java开发，如果你现在正在学习Java ，了解Java ，渴望成为一名合格的Java开发工程师，在入门学习Java的过程当中缺乏基础入门的视频教程，可以关注并私信我：01 。获取。我这里有最新的Java基础全套视频教程。