权限系统设计前言权限管理是所有后台系统的重要组成部分。或操作不当导致的风险问题，如操作失误、隐私数据泄露等问题。目前在公司负责权限，对权限的设计比较熟悉。公司采用微服务架构，权限体系天然独立。其他业务系统包括商品中心、订单中心、用户中心、仓库系统、小程序等，多个APP和十几个系统和终端1.权限模型目前最流行的权限设计模型是RBAC模型，基于角色的访问控制（Role-BasedAccessControl）1.1RBAC0模型RBAC0模型如下：这是最权威的基础，也是最核心的模型，包括用户/角色/权限，其中用户和角色是多对多的关系，角色和权限也是多对多的关系。用户是运营的主体，按类型可分为2B和2C用户。他们可以是后台管理系统的用户，也可以是OA系统的内部员工，也可以是C端用户，比如阿里云用户。角色起到桥梁的作用，连接用户和权限之间的关系。每个角色可以关联多个权限。同时，一个用户关联了多个角色，因此这个用户对多个角色拥有多个权限。可能有人会问为什么用户不直接关联权限呢？在用户基数较小的系统中，比如20人的小系统，管理员可以直接给用户关联权限，工作量不大。选择一个用户并检查所需的用户。权限已完成。但是在实际的企业系统中，用户基数比较大，而且很多都是相同的权限，只是一个共同的访问权限。如果管理员授权100人以上，工作量会很大。这里引入了“角色（Role）”的概念，一个角色可以关联多个用户，管理员只需要将角色分配给用户，那么用户就拥有该角色下的所有权限，这样的设计不仅提高了效率，还有很大的可扩展性。权限是用户可以访问的资源，包括页面权限、操作权限和数据权限：页面权限：用户登录系统后可以看到的页面，由菜单控制。菜单包括一级菜单和二级菜单，只要用户拥有一级和二级菜单的权限，那么用户就可以获得页面操作权限：即页面的功能按钮，包括查看、添加、修改、删除、审核等。当用户点击删除按钮时，后台会验证所有的用户角色。权限是否包括删除权限？如果是，则可以进行下一步，否则会提示没有权限。有的系统要求“可见时操作”，即如果页面上可以看到操作按钮，用户就可以进行操作。要实现这个需求，这里需要前端的配合。前端开发缓存用户的权限信息。页面判断用户是否有此权限，有则显示按钮，无则隐藏按钮。一定程度上提高了用户体验，但在实际场景中，可以选择是否需要数据权限：数据权限是指用户在同一页面看到的数据是不同的，比如财务部门只能查看其部门下的用户数据，采购部门只看采购部门的数据。一些大公司，在全国有很多城市和分支机构。比如杭州的用户登录系统只能看到杭州的数据，上海的用户只能看到上海的数据。解决方案通常，数据与特定的组织结构相关联。例如，在对用户进行授权时，用户选择一个角色，绑定一个机构，比如财务部或合肥分公司，则该用户就具有财务部或合肥分公司下属的数据权限。以上就是RBAC的核心设计和模型分析。该模型也称为RBAC0。在核心概念的基础上，RBAC还提供了扩展模型。包括RBAC1、RBAC2、RBAC3模型。下面分别介绍这三种类型。1.2RBAC1模型该模型引入了HierarchicalRole的概念，即角色之间存在上下级关系，角色之间的继承关系分为一般继承关系和受限继承关系。一般继承关系只要求角色继承关系是绝对偏序关系，允许角色间多重继承。受限继承关系进一步要求角色继承关系为树形结构，实现角色间的单继承。这种设计可以对角色进行分组分层，一定程度上简化了权限管理。1.3基于核心模型，RBAC2模型进行角色约束控制。RBAC2模型增加了职责分离关系，规定了何时将权限分配给角色，或者何时将角色分配给用户，以及用户在某个时刻激活时角色应该遵循的强制规则。职责分离包括静态职责分离和动态职责分离。主要包括以下约束：互斥角色：同一个用户最多只能被分配到一组互斥角色中的一个角色，支持职责分离原则。互斥角色是指两个角色各自的权限相互制约。例如财务部门有会计和审计员两个角色，这两个角色是互斥的角色，所以用户不能同时拥有这两个角色，体现了职责分离原则的基数约束：分配的用户数一个角色是有限的；一个用户可以拥有的角色数量是有限的；也应该限制一个角色对应的访问权限的数量，以控制高级权限在系统中的分配先决条件角色：即用户要想获得上级角色，必须先获得其下级角色1.4的RBAC3模型是最完善的权限管理。它以RBAC0为基础，集成了RBAC1和RBAC2。1.5用户组当平台用户基数增加，角色类型增加，有些人属性相同，比如财务部门的所有成员对于员工，如果直接给用户分配角色，管理员的工作量会很重。如果将具有相同属性的用户归为一个用户组，那么管理员直接为用户组分配角色，用户组中的每个用户都可以拥有这个角色，其他用户加入该用户组后，可以自动获得所有用户组的角色，退出用户组，同时撤销用户组下的角色，无需管理员手动管理角色。根据用户组是否有上下级关系，可以分为有上下级关系的用户组和普通用户组：有上下级关系的用户组：最典型的例子是部门和职位，大部分人可能不会把部门职位和用户群联系起来。当然，用户群体是可以扩大的。部门和职位经常用于内部管理系统。如果是面向C端的系统，比如淘宝上的商家，商家本身也有一套组织架构，比如采购部、销售部、客服部、物流等。部门等，有的人有客服权限，有的人有货架权限等，所以用户组是普通用户组，可以扩展：即没有上下级关系，有与组织结构和职位无关，也就是说可以跨部门。交叉定位，比如电商后台管理系统，有管理群体活动的作用。我们可以建立一个用户组进行群组绑定。staff等。每个公司都会涉及到组织机构和岗位，下面重点介绍这两个。1.5.1一个组织常见的组织结构如下图所示：我们可以将组织与角色联系起来。用户加入组织后，将自动获得该组织的所有角色。无需管理员手动授权，大大减少了工作量。到岗时，只需要调整机构，角色可以批量调整。该组织的另一个功能是控制数据权限。如果一个角色关联了一个组织，则该角色只能看到该组织下的数据权限。1.5.2职位假设财务部门的职位如下图所示：每个组织部门有多个职位，如财务部有主任、会计、出纳等职位。虽然都是同一个部门，但是每个职位的权限是不一样的，职位越高的人越有权力。董事拥有全部权限，会计和出纳拥有部分权限。在特殊情况下，一个人可能身穿不止一份工作。1.6包含组织/职位/用户组的模型基于以上场景，可以设计一个新的权限模型，如下图所示：根据系统的复杂程度，多对多和一对多关系一个关系可能会改变在单一系统和单一用户类型的情况下，用户和组织之间的关系是一对一的，组织和职位之间的关系是一对多的，用户和职位之间的关系是一对一的关系，组织和角色是一对一的关系，职位和角色的关系是一对一的关系，用户和用户组是多对一的关系，用户组和角色是一对一的关系，当然这些关系也可以根据具体的业务进行调整。模型设计没有死，如果小系统不需要用户群，这块可以去掉。如果是单一用户类型的分布式系统，这里的权限系统会变得非常复杂，这里引入一个“系统”的概念。此时系统架构是一个分布式系统，权限系统是独立的，负责所有系统的权限控制，其他业务系统如商品中心、订单中心、用户中心，每个系统都有自己的角色和权限，那么权限系统可以配置其他系统的角色和权限。对于多用户类型的分布式系统，如淘宝，其用户类型包括内部用户、商家和普通用户。内部用户登录多个后台管理系统，商户登录商户中心。这些用于权限控制。如果你作为架构师，我应该如何设计呢？可以在评论区留言交流哦！2.授权过程授权就是给用户授予角色。按流程可分为人工授权和审批授权。授权中心可以同时配置这两种类型，可以提高授权的灵活性。手动授权：管理员登录权限中心对用户进行授权。根据在哪个页面给用户授权有两种方式：给用户添加角色，给角色添加用户。为用户添加角色就是在用户管理页面点击用户授予角色，可以一次为用户添加多个角色；将用户添加到角色就是在角色管理页面点击角色选择多个用户，即可为用户赋予角色。向批量用户授予角色的目的。审批授权：当用户申请职位角色时，用户通过OA流程申请角色，经上级批准后即可拥有该角色，无需系统管理员手动授予。3.表结构有了上面的权限模型，设计表结构就不难了。下面是多系统下的表结构。简单的设计下，主要提供思路：4.项目中可以使用ApacheShrioSpringSecurity的权限框架A框架，它们的优缺点以及如何使用会在后面的文章中详细介绍。5.结论权限系统可以说是整个系统中最基础的，但也可以说是非常复杂的。在实际项目中，会遇到很多一个系统、多种用户类型、多种使用场景，需要具体问题具体分析，但核心的RBAC模型不变，我们可以对其进行扩展以满足需求。最后，如果您觉得本文对您有帮助，可以点击再次阅读，感谢您的支持！
