网站权限设计方案 第1篇
我们创建角色是为了解决用户数量大的情况下，用户分配权限繁琐以及用户-权限关系维护成本高的问题。抽象出一个角色，把需要一起操作的权限分配给这个角色，把角色赋予用户，用户就拥有了角色上的权限，这样避免了一个个的给用户分配权限，节省了大量的资源。
同样的如果有一批用户需要相同的角色，我们也需要一个个的给用户分配角色，比如一个公司的客服部门有500多个人，有一天研发部研发了一套查询后台数据的产品，客服的小伙伴都需要使用，但是客服由于之前并没有统一的一个角色给到所有的客服小伙伴，这时候需要新加一个角色，把权限分配给该角色，然后再把角色一个个分配给客服人员，这时候会发现给500个用户一个个添加角色非常的麻烦。但是客服人员又有共同的属性，所以我们可以创建一个用户组，所有的客服人员都属于客服用户组，把角色分配给客服用户组，这个用户组下面的所有用户就拥有了需要的权限。
RBAC模型添加用户组之后的模型图如下所示：
很多朋友会问，用户组和角色有什么区别呢？简单的来说，用户组是一群用户的组合，而角色是用户和权限之间的桥梁。 用户组把相同属性的用户组合起来，比如同一个项目的开发、产品、测试可以是一个用户组，同一个部门的相同职位的员工可以是一个用户组， 一个用户组可以是一个职级，可以是一个部门，可以是一起做事情的来自不同岗位的人。
用户可以分组，权限也可以分组，权限特别多的情况下，可以把一个模块的权限组合起来成为一个权限组，权限组也是解决权限和角色对应关系复杂的问题。
比如我们定义权限的时候一级菜单、二级菜单、按钮都可以是权限，一个一级菜单下面有几十个二级菜单，每个二级菜单下面又有几十个按钮，这时候我们把权限一个个分配给角色也是非常麻烦的，可以采用分组的方法把权限分组，然后把分好的组赋予角色就可以了。
给权限分组也是个技术活，需要理清楚权限之间的关系，比如支付的运营后台我们需要查各种信息，账务的数据、订单的数据、商户的数据等等，这些查询的数据并不在一个页面，每个页面也有很多按钮，我们可以把这几个页面以及按钮对应的权限组合成一个权限组赋予角色。加入权限组之后的RBAC模型如下所示：
实际工作中我们很少给权限分组，给用户分组的场景会多一些，有的时候用户组也可以直接和权限关联，这个看实际的业务场景是否需要，权限模型没有统一的，业务越复杂业务模型会约多样化。
每个公司都有自己的组织架构，很多时候权限的分配可以根据组织架构来划分。因为同一个组织内的小伙伴使用的大部分权限是一样的。如下所示一个公司的组织架构图：
按照这个组织架构，每一个组织里的成员使用的基础权限很可能是一样的，比如人力资源都需要看到人才招聘的相关信息，市场推广都需要看到行业分析的相关信息，按照组织来分配角色会有很多优势：
实现权限分配的自动化： 和组织关系打通之后，按照组织来分配角色，如果有新入职的用户，被划分在某个组织下面之后，会自动获取该组织下所有的权限，无需人工分配。又比如有用户调岗，只需要把组织关系调整就可以了，权限会跟着组织关系自动调整，也无需人工干预。这么做首先需要把权限和组织关系打通。
控制数据权限： 把角色关联到组织，组织里的成员只能看到本组织下的数据，比如市场推广和大客定制，市场推广针对的是零散的客户，大可定制针对的是有一定体量的客户，相互的数据虽然在一个平台，但是只能看自己组织下的数据。
加入组织之后的RBAC模型如下所示：
用户可以在多个组织中，因为组织也有层级结构，一个组织里只可以有多个用户，所以用户和组织的关系是多对多的关系，组织和角色的关系是一对一的关系。这个在工作中可以根据实际情况来确定对应关系。
一个组织下面会有很多职位，比如财务管理会有财务总监、财务主管、会计、出纳员等职位，每个职位需要的权限是不一样的，可以像组织那样根据职位来分配不同的角色，由于一个人的职位是固定的，所以用户跟职位的对应关系时一对一的关系，职位跟角色的对应关系可以是多对多的关系。加入职位的RBAC模型如下所示：
RBAC模型根据不同业务场景的需要会有很多种演变，实际工作中业务是非常复杂的，权限分配也是非常复杂的，想要做出通用且高效的模型很困难。我们把RBAC模型的演变汇总起来会是一个支撑大数据量以及复杂业务的理想的模型。把RBAC、RBAC1、RBAC2、用户组、组织、职位汇总起来的模型如下所示：
按照这个模型基本上能够解决所有的权限问题，其中的对应关系可以根据实际的业务情况来确定，一般情况下，组织和职位是一对多的关系，特殊情况下可以有多对多的情况，需要根据实际情况来定。
理想的RBAC模型并不是说我们一开始建权限模型就可以这么做，而是数据体量、业务复杂度达到一定程度之后可以使用这个模型来解决权限的问题，如果数据量特别少，比如刚成立的公司只有十几个人，那完全可以用用户-权限模型，都没有必要使用RBAC模型。
标准RBAC模型的表是比较简单了，要表示用户-角色-权限三者之前的关系，首先要创建用户表、角色表、权限表，用户和角色是多对多的关系，角色和权限是多对多的关系，需要再创建两章关系表，分别是用户-角色关系表和角色-权限关系表。这六张表的ER图如下所示：
理想的RBAC模型是标准RBAC模型经过多次扩展得到的，表结构也会比较复杂，因为要维护很多关系，如下图所示是理想的RBAC模型的ER图：
这里面需要强调的是角色互斥表，互斥的关系可以放在角色上，也可以放在权限上，看实际工作的需求。
本文从易到难非常详细的介绍了权限模型的设计，在工作中需要根据实际情况来定义模型，千人以内的公司使用RBAC模型是完全够用的，没有必要吧权限模型设计的过于复杂。模型的选择要根据具体情况，比如公司体量、业务类型、人员数量等。
总之最适合自己公司的模型就是最好的模型，权限模式和设计模式是一样的，都是为了更好的解决问题，不要为了使用模型而使用模型。
网站权限设计方案 第2篇
迄今为止最为普及的权限设计模型是 RBAC 模型, 基于角色的访问控制（Role-Based Access Control)
RBAC0 模型
RBAC0 模型如下:
这是权限最基础也是最核心的模型, 它包括用户 / 角色 / 权限, 其中用户和角色是多对多的关系, 角色和权限也是多对多的关系。
用户是发起操作的主体, 按类型分可分为 2B 和 2C 用户, 可以是后台管理系统的用户, 可以是 OA 系统的内部员工, 也可以是面向 C 端的用户, 比如阿里云的用户。
角色起到了桥梁的作用, 连接了用户和权限的关系, 每个角色可以关联多个权限, 同时一个用户关联多个角色, 那么这个用户就有了多个角色的多个权限。
有人会问了为什么用户不直接关联权限呢？在用户基数小的系统, 比如 20 个人的小系统，管理员可以直接把用户和权限关联，工作量并不大，选择一个用户勾选下需要的权限就完事了。
但是在实际企业系统中，用户基数比较大, 其中很多人的权限都是一样的，就是个普通访问权限，如果管理员给 100 人甚至更多授权, 工作量巨大。
这就引入了 _角色 (Role)_ 概念, 一个角色可以与多个用户关联, 管理员只需要把该角色赋予用户, 那么用户就有了该角色下的所有权限, 这样设计既提升了效率, 也有很大的拓展性。
是用户可以访问的资源, 包括页面权限, 操作权限, 数据权限:
即用户登录系统可以看到的页面, 由菜单来控制, 菜单包括一级菜单和二级菜单, 只要用户有一级和二级菜单的权限, 那么用户就可以访问页面
网站权限设计方案 第3篇
Control List，访问控制列表，是⼀种直接的权限管理方式，用户的权限是直接与资源相关联的。 2.每个资源都有⼀个访问控制列表，该列表指定了哪些⽤户或⽤户组对该资源具有哪些权限
1.直观易懂：用户和资源的权限关系直接明了，易于理解和配置。 2.控制精确：可以精确地控制每个⽤户对每个资源的访问权限。
1.当用户或资源数量多时，ACL的管理会变得复杂和繁琐，维护成本高 2.当需要给几十万个用户增加或者移除某个权限时，就麻烦了
Access Control，基于⻆⾊的访问控制，核⼼思想是将权限与⻆⾊相关联，⽽不是直接与⽤户相关联。 2.在RBAC中，⻆⾊是权限的集合，⽤户通过成为适当⻆⾊的成员⽽得到这些⻆⾊的权限。 3.简化了⽤户与权限的管理，通过对⽤户进⾏分类，使得⻆⾊与权限关联起来。 4.⽐如上述案例⼏⼗万个⽤户，具备某个⻆⾊，如果需要加权限只需要对应的⻆⾊增加权限即可
1、灵活性⾼：可以动态地分配和撤销⻆⾊的权限，适应组织结构和业务2流程的变化。 2、管理便捷：通过管理⻆⾊和权限的映射关系，简化⽤户权限的管理过程。 3、可扩展性好：可以⽅便地添加新的⻆⾊和权限，更好的适应业务的发展
1、开发相对ACL更为复杂，以及在⻆⾊和权限数量多时，管理复杂度会上升
网站权限设计方案 第4篇
在前面我们提到，有时候在Validation中，可以“消除角色”。这带来的代价就是会根据数据的状态创建不同的权限，使得权限增多。比如高中有3个年级，我们想分别对这三个年级有不同的权限控制，就得创建三个权限。
另一种情况是Access对API的关系。在上篇文章中，笔者推荐的是以“业务操作”为粒度。比如发朋友圈，假设有三个步骤：上传图片，获取当前位置，确认发布。我们其实只需要一个发朋友圈的Access，而不是三个Access。但这个Access其实对应的是三个API，而每个API又可能不止一个Access。比如上传文件，我们在聊天的时候也会用到这个API。所以Access与API是多对多的关系。
权限多了，就不容易管理。所以可以抽象出一个权限组的概念，来更好地管理权限。
当然了，增加用户组和权限组都会带来一定的复杂性，使现有的权限模型变得更加复杂。所以再次提醒大家，在做权限设计的时候一定要遵循“够用就行”的原则，切勿过度设计。
以上两篇文章是笔者对权限系统设计的理解和总结。如果读者有任何疑惑的地方，或理解不一致的地方。欢迎留言讨论~
这个方向初期比较容易入门一些，掌握一些基本技术，拿起各种现成的工具就可以开黑了。不过，要想从脚本小子变成hei客大神，这个方向越往后，需要学习和掌握的东西就会越来越多，以下是学习网络安全需要走的方向：
上面介绍了技术分类和学习路线，这里来谈一下学习方法： ## 视频学习
网站权限设计方案 第5篇
举个例子，一家支付公司有运营后台，运营后台可以查到所有的商户信息，法人代表信息，交易信息以及费率配置信息，如果我们把这些信息不加筛选都给到公司的每一个小伙伴，那么跑市场的都可以操作商家的费率信息，如果一个不小心把费率改了会造成巨大的损失。
又比如商户的信息都是非常隐秘的，有些居心不良的小伙伴把这些信息拿出来卖给商家的竞争对手，会给商家造成严重的不良后果。虽然这么做都是个别人人为的过错，但是制度上如果本身这些信息不开放出来就能在很大程度上避免违法乱纪的事情发生了。
总体来讲权限管理是公司数据安全的重要保证，针对不同的岗位，不同的级别看到的数据是不一样的，操作数据的限制也是不一样的。比如涉及到资金的信息只开放给财务的相关岗位，涉及到配置的信息只开放给运营的相关岗位，这样各司其职能避免很多不必要的安全问题。
如何让各个岗位的人在系统上各司其职，就是权限管理要解决的问题。
如下图所示：
按照这个架构，按钮的父级是二级菜单，二级菜单的父级是一级菜单，这样用户申请权限的时候非常清晰的看到自己需要哪些权限。
权限结构梳理清晰之后，需要思考怎么把权限分配给用户，用户少的情况下，可以直接分配，一个用户可以有多个权限，统一一个权限可以被多个用户拥有，用户-权限的模型结构如下所示：
这种模型能够满足权限的基本分配能力，但是随着用户数量的增长，这种模型的弊端就凸显出来了，每一个用户都需要去分配权限，非常的浪费管理员的时间和精力，并且用户和权限杂乱的对应关系会给后期带来巨大的维护成本。用户-权限对应关系图：
这种对应关系在用户多的情况下基本无法维护了。其实很多用户负责同一个业务模块所需要的权限是一样的，这样的话我们是不是可以借助第三个媒介，把需要相同的权限都分配给这个媒介，然后用户和媒介关联起来，用户就拥有了媒介的权限了。这就是经典的RBAC模型，其中媒介就是我们通常所说的角色。
有了角色之后可以把权限分配给角色，需要相同权限的用户和角色对应起来就可以了，一个权限可以分配给多个角色，一个角色可以拥有多个权限，同样一个用户可以分配多个角色，一个角色也可以对应多个用户，对应模型如下所示：
这就是经典的RBAC模型了（role-based-access-control），在这里面角色起到了桥梁左右，连接了用户和权限的关系，每个角色可以拥有多个权限，每个用户可以分配多个角色，这样用户就拥有了多个角色的多个权限。
同时因为有角色作为媒介，大大降低了错综复杂的交互关系，比如一家有上万人的公司，角色可能只需要几百个就搞定了，因为很多用户需要的权限是一样的，分配一样的角色就可以了。这种模型的对应关系图如下所示：
用户和角色，角色和权限都是多对多的关系，这种模型是最通用的权限管理模型，节省了很大的权限维护成本， 但是实际的业务千变万化，权限管理的模型也需要根据不同的业务模型适当的调整，比如一个公司内部的组织架构是分层级的，层级越高权限越大，因为层级高的人不仅要拥有自己下属拥有的权限，二期还要有一些额外的权限。
RBAC模型可以给不同层级的人分配不同的角色，层级高的对应角色的权限就多，这样的处理方式可以解决问题，但是有没有更好的解决办法呢，答案肯定是有的，这就引出角色继承的RBAC模型。
另外，如果你近期准备面试跳槽，建议在Java面试库小程序在线刷题，涵盖 2000+ 道 Java 面试题，几乎覆盖了所有主流技术面试题。
角色继承的RBAC模型又称RBAC1模型。每个公司都有自己的组织架构，比如公司里管理财务的人员有财务总监、财务主管、出纳员等，财务主管需要拥有但不限于出纳员的权限，财务总监需要拥有但不限于财务主管的权限，像这种管理关系向下兼容的模式就需要用到角色继承的RBAC模型。角色继承的RBAC模型的思路是上层角色继承下层角色的所有权限，并且可以额外拥有其他权限。
模型如下所示：
从模型图中可以看出下级角色拥有的权限，上级角色都拥有，并且上级角色可以拥有其他的权限。角色的层级关系可以分为两种，一种是下级角色只能拥有一个上级角色，但是上级角色可以拥有多个下级角色，这种结构用图形表示是一个树形结构，如下图所示：
还有一种关系是下级角色可以拥有多个上级角色，上级角色也可以拥有多个下级角色，这种结构用图形表示是一个有向无环图，如下图所示：
树形图是我们比较常用的，因为一个用户一般情况下不会同时有多个直属上级，比如财务部只能有一个财务总监，但是可以有多个财务主管和收纳员。
带约束的RBAC模型又成RBAC2模型。在实际工作中，为了安全的考虑会有很多约束条件，比如财务部里同一个人不能即是会计又是审核员，跟一个人同一时间不能即是运动员又是裁判员是一个道理的，又比如财务部的审核员不能超过2个，不能1个也没有。因为角色和权限是关联的，所以我们做好角色的约束就可以了。
常见的约束条件有：角色互斥、基数约束、先决条件约束等。
网站权限设计方案 第6篇
1、地址： 2、易于使⽤：Shiro的API设计简洁直观，能够快速地集成到应⽤程序中 3、功能全⾯：提供了身份验证、授权、加密和会话管理等安全相关的功能，满⾜应⽤程序安全性的基本需求。 4、灵活性：Shiro⽀持多种应⽤场景，包括Web、⾮Web、分布式和云环境等，能够灵活地应对不同的需求。
1、Shiro适⽤于各种Java应⽤程序，特别是那些需要快速集成安全功能的应⽤程序。 2、⽆论是Web应⽤、桌⾯应⽤还是分布式系统，Shiro都能提供强⼤的功能⽀持。
易于学习和使⽤：对于初学者来说，Shiro的⽂档和教程⾮常丰富，易于上⼿。 轻量级：相对于其他安全框架，Shiro更加轻量级，对系统资源的消耗⼩。
社区⽀持：虽然Shiro的社区活跃，但相对于Spring Security等框架，其社区规模和资源可能少。
1、地址： 2、与Spring集成：Spring Security与Spring框架⽆缝集成，使得在Spring应⽤中使⽤安全功能变得⾮常简单。 3、⾼度可定制：Spring Security提供了丰富的配置选项和扩展点，可以根据具体需求进⾏⾼度定制。 4、强⼤的功能：除了基本的身份验证和授权功能外，Spring Security还⽀持OAuth2、OpenID Connect等⾼级功能。
1、Spring Security主要适⽤于基于Spring框架的应⽤程序，特别是那些需要⾼度可定制性和强⼤功能⽀持的应⽤程序。
1、与Spring深度集成：对于使⽤Spring框架的开发者来说，Spring Security是⾸选的安全框架。 2、强⼤的社区⽀持：Spring Security拥有庞⼤的社区和丰富的资源，可以快速解决遇到的问题。
1、学习曲线陡：相对于Shiro，Spring Security的学习曲线可能陡，需要⼀定的时间来掌握。 2、相对较重：由于提供了丰富的功能和配置选项，Spring Security相对于Shiro可能为重量级
1、地址： 2、功能全⾯：提供了登录认证、权限认证、单点登录、、微服务鉴权等功能，满⾜了多种场景下的权限管理需求。 3、简单易⽤：Sa-Token的API设计简洁直观，易于上⼿。开发⼈员可以快速集成到项⽬中，减少开发成本和时间。 4、轻量级：相⽐其他权限框架，Sa-Token更加轻量级，对系统资源的消耗⼩，适⽤于各种规模的项⽬。 5、灵活性：Sa-Token提供了丰富的配置选项和扩展点，可以根据具体需求进⾏定制和扩展。
1、Sa-Token适⽤于各种需要进⾏权限管理的Java应⽤程序，包括但不限于Web应⽤、分布式系统、微服务架构等。 2、⽆论是简单的⽤户⻆⾊权限管理，还是复杂的业务逻辑权限控制，Sa-Token都能提供有效的解决⽅案
网站权限设计方案 第7篇
这就会带来一个问题。比如我们删除一个数据，会根据这个数据的状态来做验权。后端肯定是需要写这个验证逻辑的，如果前端再写一份，那就会在前后端各自维护一段相同功能的逻辑。后期如果要修改逻辑的话，就需要前后端同时修改，造成代码维护上的不便。
还有一种情况是不适用于在前端写验证逻辑的。就是有些比较复杂的Validation，需要查其它数据库甚至是其它服务的数据，这种情况就不适合在前端做，不然可能要多Call好几个API。
网站权限设计方案 第8篇
对于一个操作的权限控制，通常有两种情况：
综上两种实现的比较，笔者推荐的方案是：后端返回的Flag只与Validation有关，前端写死的代码里只与Access有关。
下面是以Vue为例的一个示例代码：
当然，不同团队可以根据自己的实际情况进行取舍和改进。
有时候我们可能会根据业务需求，对RBAC模型进行一定的增强。比如用户组、权限组等。