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