后台系统重要组成的权限管理：普及的RBAC模型
前言
永久管理是所有涉及的背景系统的重要组成部分。主要目的是控制权限以访问不同人的资源，以避免由于缺乏许可控制或操作不当而引起的风险问题，例如错误，隐私数据泄漏等。
目前，公司负责权限，因此当局的设计更加熟悉。该公司采用微服务架构，并且权威系统自然独立出现。其他业务系统包括商品中心，订单中心，用户中心，仓库系统，小程序，小程序，有十几个系统和终端，例如多个应用程序
◆1。权限模型
到目前为止，最受欢迎的权威设计模型是RBAC模型，基于角色的访问控制（角色）
1.1型号
该模型如下：
这是权限的最基本和核心模型。它包括用户/角色/权限。其中，用户和角色是更多的关系，角色和权限之间的关系也更多。
用户是操作的主体。根据类型，可以将其分为2B和2C用户。它可以是背景管理系统中的用户。它可以是OA系统的内部员工或面向用户的用户，例如 用户。
角色扮演桥梁的角色，连接用户与权限之间的关系。每个字符都可以关联多个权限。同时，一个用户会关联多个字符，然后该用户具有多个字符的多个权限。
有人会问为什么用户不直接与权威联系？在具有较小用户群的系统中，例如20人的小型系统，管理员可以直接将用户和权限关联。工作量不大。选择用户检查所需的权限。
但是，在实际的企业系统中，用户群相对较大，其中许多具有相同的权限，这是普通的访问权限。如果管理员授予100人或更多的授权人员，则工作量是巨大的。
这介绍了“角色”的概念。一个字符可以与多个用户关联。管理员只需要将角色赋予用户，因此用户拥有该角色的所有权。也有很大的扩展。
这是用户可以访问的资源，包括页面权限，操作权限，数据权限：
也就是说，可以看到用户登录系统的页面，该页面由菜单控制。菜单包括第一个级菜单和辅助菜单。只要很长
也就是说，页面的功能按钮，包括查看，添加，修改，删除，评论等。当用户单击删除按钮时，背景将检查用户角色下的所有权是否包含删除权限。如果是这样，您可以执行下一步，否则它是无与伦比的。
一些系统需要“可见的可以操作”，这意味着，如果可以在页面上看到操作按钮，则用户可以操作。为了实现此目的，要求页面确定用户是否包含此权限。如果有的话，将显示该按钮。如果没有，则隐藏了按钮。
在某种程度上，用户体验得到了改善，但是您可以选择是否需要在实际场景中执行此操作。
数据权限是用户在同一页面上看到的不同数据。例如，财政部只能在其部门下查看用户数据，而采购部门仅读取采购部门的数据。
在一些大公司中，全国有许多城市和分支机构。例如，用户只能看到数据。上海用户只能看到上海数据。该解决方案通常将数据与特定的组织结构相关联。本质
例如，在授权用户时，用户选择一个角色来绑定组织（例如财务部门或分支机构），然后用户在财务部门或分支机构下具有数据权限。
以上是RBAC的核心设计和模型分析。此模型也被称为。基于核心概念，RBAC还提供扩展模式。包括模型。下面介绍以下三种类型
1.2型号
该模型介绍了角色继承的概念（角色），即角色具有上级和较低级别之间的关系。字符之间的继承关系可以分为一般的继承和有限的继承关系。
通常，继承关系要求字符继承关系是绝对的序列关系，允许字符之间的多重继承。
受限制的继承关系进一步要求字符继承关系是一种树结构，它实现了字符之间的单个继承。该设计可以使角色的分组和分层提供，从而在一定程度上简化了权限管理。
1.3型号
基于核心模型，执行了角色约束控制，并将责任分离关系添加到模型中。
它规定，当授权给予角色或赋予用户角色时，以及当用户在特定时刻激活角色时应遵循的强制性规则。
责任分离包括静态责任分离和动态责任分离。它主要包括以下约束：
同一用户只能分配给一组相互排斥的字符中责任分离的原则。
相互角色是指限制彼此权限的两个角色。例如，财政部有两个角色：会计和审稿人。它们是互斥的角色，因此用户不能同时扮演这两个角色，反映了原理
字符分配的用户数量有限；用户可以拥有的字符数量；
也就是说，用户希望扮演卓越的角色，他必须首先获得下一个级别的角色
1.4型号
也就是说，最全面的权威管理是基于和谐的整合。
1.5用户组
当平台的基础增加时，字符类型会增加，并且有些人具有相同的属性，例如财务部的所有员工，如果他们将角色直接分配给用户，则管理员的工作负载将非常大。
如果将同一属性的用户分类为用户组，则管理员将角色直接分配给用户组。用户组中的每个用户都可以具有此角色。在其他用户加入用户组之后，他们可以自动获取用户组自动获得用户组所有角色已退出了用户组，同时也已取消了用户组的角色，而没有经理管理员手动管理角色。
根据用户组是否具有较高的关系，可以将其分为具有下属的用户组和普通用户组：
最典型的例子是部门和职位。大多数人可能不会将部门职位与用户组联系起来。
当然，用户组可以扩展，如果是C侧系统，则在内部管理系统中经常使用部门和职位。
例如，淘宝的商人，商人本身也有一套组织结构，例如采购部门，销售部门，客户服务部，物流部门等。有些人拥有客户服务许可，有些人拥有授权因此，货架等。因此，用户组可以将其扩展。
也就是说，下属和较低的关系之间没有关系，组织与组织结构无关，这意味着它可以跨部门和职位。
例如，在电子商务公司的背景管理系统中具有管理角色。我们可以设置组用户组。该小组可以包括研发部门的背景开发商，运营部门的运营人员，采购部门的人员等。
每个公司都涉及组织和职位，这两个公司在下面介绍。
1.5.1组织
共同的组织结构如下：
我们可以将组织与该角色联系起来。用户加入组织后，我们将自动获得组织的所有角色。无需手动授予它以大大减少工作量。批次调整。
组织的另一个角色是控制数据权限并将角色与组织相关联，因此角色只能在组织下看到数据权限。
1.5.2位置
假设财政部的立场如下所示：
每个组织下面都有多个职位，例如董事，会计，出纳和其他职位。尽管他们在同一部门中，但每个职位的权限都不同，高职位具有更大的权力。
董事拥有所有权，会计和收银员拥有部分权限。在特殊情况下，一个人可能有多个职位。
1.6包含组织/职位/用户组的型号
根据上述情况，可以设计新的权威模型，如下图所示：
根据系统的复杂性，多个 - 多个关系和一个关系可能会改变
1。对于单个系统和单个用户类型，用户和组织是一个 - 一项关系，组织和位置是一个关系。用户和位置是一个关系。这是与角色的一种关系。用户和用户组更多。用户组和角色是一个关系的关系。当然，这些关系也可以根据特定业务进行调整。
模型设计还没有死。如果小型系统不需要用户组，则可以删除此部分。
2。在分布式系统和单个用户类型的情况下，权威系统在这里变得非常复杂。这是一个“系统”概念。
3。目前，系统体系结构是一个分布式系统。权威系统是独立的，负责所有系统的控制。其他业务系统，例如商品中心，订单中心，用户中心以及每个系统都有自己的角色和权限。该系统可以配置其他系统的角色和权限。
4。对于分布式系统和多种用户类型，例如淘宝，其用户类型包括内部用户，商人，普通用户，内部用户登录到多个背景管理系统，商人登录到商人中心，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制，这些权限控制这些权限控制，这些权限控制。如果您是建筑师，如何设计它？伟大的上帝可以在评论区留言！
◆2。授权过程
授权是将角色授予用户，并且可以根据过程将其分为手动授权和批准授权。当局中心可以同时配置这两个中心，这可以提高授权的灵活性。
管理员登录当局中心由用户授权。根据页面授权，它分为两种方式：将字符添加到用户并将用户添加到字符中。
为用户添加角色是在用户管理页面上。单击用户授予该角色。您可以一次向用户添加多个字符；将用户添加到字符管理页面上的字符中。单击某个角色，选择多个用户，然后为其实现。批处理用户授予该角色的目的。
也就是说，用户应用职位角色，然后用户通过OA过程应用角色，然后由上级批准。用户可以扮演角色，并且不需要系统管理员手动。
◆3。表结构
使用上述权限模型，设计表结构并不困难。以下是多个系统下的表结构。在简单的设计下，主要思想是提供想法：
◆4。权限框架
其中一个框架可以在项目中使用，它们的优势和缺点以及如何使用它们的优势和缺点将在后来的文章中详细介绍。
◆5。结论
可以说，权限系统是整个系统中最基本的，也可能非常复杂。在实际项目中，遇到了多个系统，多个用户类型和多种用途方案。这需要特定的问题和特定的分析，但是最多的核心RBAC模型是恒定的，我们可以扩展它以满足需求。