RBAC简介

什么是权限管理

基本上涉及到用户参与的系统都要进行权限管理，权限管理属于系统安全的范畴，权限管理实现对用户访问系统的控制，按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权的资源。

权限管理包括用户身份认证和授权两部分，简称认证授权。对于需要访问控制的资源用户首先经过身份认证，认证通过后用户具有该资源的访问权限方可访问。

用户身份认证

身份认证，就是判断一个用户是否为合法用户的处理过程。最常用的简单身份认证方式是系统通过核对用户输入的用户名和口令，看其是否与系统中存储的该用户的用户名和口令一致，来判断用户身份是否正确。对于采用指纹等系统，则出示指纹；对于硬件key等刷卡系统，则需要刷卡。

用户名密码身份认证流程

关键对象

上边的流程图中需要理解以下关键对象：

：主体

访问系统的用户，主体可以是用户、程序等，进行认证的都称为主体；

n ：身份信息

是主体（subject）进行身份认证的标识，标识必须具有唯一性，如用户名、手机号、邮箱地址等，一个主体可以有多个身份，但是必须有一个主身份（primaryprincipal）。

n credential ：凭证信息

是只有主体自己知道的安全信息，如密码、证书等。

授权

授权，即访问控制，控制谁能访问哪些资源。主体进行身份认证后需要分配权限方可访问系统的资源，对于某些资源没有权限是无法访问的。

授权流程

下图中橙色为授权流程。

关键对象

授权可简单理解为who对what(which)进行how操作：

nwho，即主体（subject），主体需要访问系统中的资源。

nwhat，即资源（resource），如系统菜单、页面、按钮、类方法、系统商品信息等。资源包括资源类型和资源实例，比如商品信息为资源类型，类型为t01的商品为资源实例，编号为001的商品信息也属于资源实例。

nhow，权限/许可（permission），规定了主体对资源的操作许可，权限离开资源没有意义，如用户查询权限、用户添加权限、某个类方法的调用权限、编号为001用户的修改权限等，通过权限可知主体对哪些资源都有哪些操作许可。

权限分为粗颗粒和细颗粒，粗颗粒权限是指对资源类型的权限，细颗粒权限是对资源实例的权限。

主体、资源、权限关系如下图：

权限模型

对上节中的主体、资源、权限通过数据模型表示。

主体（账号、密码）

资源（资源名称、访问地址）

权限（权限名称、资源id）

角色（角色名称）

角色和权限关系（角色id、权限id）

主体和角色关系（主体id、角色id）

如下图：

通常企业开发中将资源和权限表合并为一张权限表，如下：

资源（资源名称、访问地址）

权限（权限名称、资源id）

合并为：

权限（权限名称、资源名称、资源访问地址）

上图常被称为权限管理的通用模型，不过企业在开发中根据系统自身的特点还会对上图进行修改，但是用户、角色、权限、用户角色关系、角色权限关系是需要去理解的。

权限分配

对主体分配权限，主体只允许在权限范围内对资源进行操作，比如：对u01用户分配商品修改权限，u01用户只能对商品进行修改。

权限分配的数据通常需要持久化，根据上边的数据模型创建表并将用户的权限信息存储在数据库中。

权限控制

用户拥有了权限即可操作权限范围内的资源，系统不知道主体是否具有访问权限需要对用户的访问进行控制。

基于角色的访问控制

rbac基于角色的访问控制（role-basedaccesscontrol）是以角色为中心进行访问控制，比如：主体的角色为总经理可以查询企业运营报表，查询员工工资信息等，访问控制流程如下：

上图中的判断逻辑代码可以理解为：

缺点：以角色进行访问控制粒度较粗，如果上图中查询工资所需要的角色变化为总经理和部门经理，此时就需要修改判断逻辑为“判断主体的角色是否是总经理或部门经理”，系统可扩展性差。

修改代码如下：

基于资源的访问控制

rbac基于资源的访问控制（resource-basedaccesscontrol）是以资源为中心进行访问控制，比如：主体必须具有查询工资权限才可以查询员工工资信息等，访问控制流程如下：

上图中的判断逻辑代码可以理解为：

优点：系统设计时定义好查询工资的权限标识，即使查询工资所需要的角色变化为总经理和部门经理也只需要将“查询工资信息权限”添加到“部门经理角色”的权限列表中，判断逻辑不用修改，系统可扩展性强。

权限管理解决方案

粗颗粒度和细颗粒度

什么是粗颗粒度和细颗粒度

对资源类型的管理称为粗颗粒度权限管理，即只控制到菜单、按钮、方法，粗粒度的例子比如：用户具有用户管理的权限，具有导出订单明细的权限。对资源实例的控制称为细颗粒度权限管理，即控制到数据级别的权限，比如：用户只允许修改本部门的员工信息，用户只允许导出自己创建的订单明细。

如何实现粗颗粒度和细颗粒度

对于粗颗粒度的权限管理可以很容易做系统架构级别的功能，即系统功能操作使用统一的粗颗粒度的权限管理。

对于细颗粒度的权限管理不建议做成系统架构级别的功能，因为对数据级别的控制是系统的业务需求，随着业务需求的变更业务功能变化的可能性很大，建议对数据级别的权限控制在业务层个性化开发，比如：用户只允许修改自己创建的商品信息可以在service接口添加校验实现，service接口需要传入当前操作人的标识，与商品信息创建人标识对比，不一致则不允许修改商品信息。

RBAC简介

RBAC（Role-Based Access Control）是一种基于角色的访问控制机制，它支持最小权限原则、责任分离原则和数据抽象原则。

最小权限原则在RBAC中通过将角色配置为完成任务所需的最小权限集来实现。 这种配置确保了用户只有执行其职责所需的权限，从而降低了安全风险。

责任分离原则在RBAC中通过将敏感任务分配给相互独立互斥的角色来实现。 例如，一个记账员和财务管理员可以共同参与同一笔账目，但他们的职责不同，确保了责任的分离，有助于减少错误和欺诈。

数据抽象原则在RBAC中通过将权限抽象为更具体的概念，如财务操作中的借款、存款等，而不是操作系统提供的常规读、写、执行权限。 这种抽象使权限管理更加直观和高效。

RBAC的复杂性在于其管理的多面性，涉及用户与角色的指派、角色与权限的指派，以及角色与角色的指派等。 这些活动需要将用户和权限进行关联，而这些通常由不同的管理员或管理角色进行。 通常，给角色分配权限是应用管理员的职责，如银行应用中，将借款、存款操作权限分配给出纳角色，将审批贷款操作权限分配给经理角色。 而具体人员与角色的指派则属于人事管理范畴。 角色与角色的指派则涵盖了用户与角色、角色与权限的一些特点，同时体现了更广泛的策略。

总的来说，RBAC提供了一种灵活、高效且安全的访问控制机制，通过精细的角色配置和权限管理，确保了最小权限原则、责任分离原则和数据抽象原则的实现，为组织提供了强大的安全保障。

基于角色的访问控制（Role-Based Access Control）作为传统访问控制（自主访问，强制访问）的有前景的代替受到广泛的关注。 在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。 这就极大地简化了权限的管理。 在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。 角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。 角色与角色的关系可以建立起来以囊括更广泛的客观情况。

各大高校名师重磅推荐：很全的 Java 权限认证框架！

sa-token是一个功能全面且轻量级的Java权限认证框架，可高效解决登录认证、权限控制、会话管理等多种权限相关问题，适用于多种业务场景。

一文看懂权限设计：基于RBAC模型

权限设计不管在C端还是B端产品产品设计中都避免不了，了解权限设计思路是产品经理在职业发展的道路上必不可少的一步。 特别是B端产品设计，每个新功能的增加都需要考虑权限，本文主要目的带着你了解目前主流的用户权限是如何设计的。 本文主要分为以下三个部分： 为什么要做权限设计？ 怎么做：RBAC模型介绍 常见应用案例：C端&B端 扩展 在文明的社会，每个人都生活在秩序当中，生活需要秩序，同样产品设计中也需要秩序，这种秩序的表达就是用户权限。 做用户权限设置是为了更好的管理用户，从而达到良好的产品运转机制。 B端产品通过权限设计可以相当大的资源外漏，从而降低企业风险。 RBAC模型目前是大部分公司主流的权限管理，因集合自助访问控制（DAC）和强制访问控制（MAC）两者的优点。 RBAC是Role-BasedAccess Control的英文缩写，意思是基于角色访问控制。 RBAC实际上就是针对产品去发掘需求时所用到的Who（角色）、What（拥有什么资源）、How（有哪些操作）的方式。 在RBAC模型中，who、what、how构成了访问权限三元组，也就是“Who对What进行How的操作。 RBAC主要包含四个子模型：RBAC0、RBAC1、RBAC2和RBAC3，整体又叫做RBAC96。 RBAC0： RBAC0是RBAC96模型家族中的基础，也称作核心部分，RBAC1、RBAC2和RBAC3是在此基础之上发展演变而来。 我们看到的可以理解它是由四个部分组成：用户、角色、会话、权限，这就导致了这种分配关系是多对多：用户对应多个角色、角色对应多个权限。 用户与会话一对一，会话与角色一对多；如下图：RBAC1： RBAC1是在RBAC0模型基础之上增加了角色分层概念和角色之间的继承关系。 角色分层指的是同一个角色可以用不同等级，不同等级又对应着不同的权限；角色继承关系指的是角色之间可以转移权限，比如A员工离职、B员工入职，两人处于同一角色。 管理员可以将A员工的权限转移B员工头上。 如下图：RBAC2： RBAC1是在RBAC0模型基础之上增加了角色约束，主要约束哪些操作是可进行，哪些是不可进行。 主要约束有以下三个方面： 角色互斥约束：是指在系统运行中,只可以同时激活运行时互斥角色集合中的一个角色; 角色基数约束：是限制某一个用户最多被分配或者激活的角色数目,或者限制某一个角色最多被赋予的权限数目; 先决条件角色约束：是指某些用户只有在己经拥有特定角色的前提下,才能被分配到某种角色,或者某种角色只有在已经被分配到特定权限的前提下,才能被赋予某些权限。 如下图：RBAC3： RBAC3则是集聚了RBAC1和RBAC2的全部特点,同时将角色继承关系和约束条件关系两者都融入到模型中。 如下图： RBAC模型通过给新用户分配相应的角色即可授予其相应的访问权限,这种灵活的角色映射机制大大降低了管理的复杂性,提高了系统的可扩展性。 模型主要解决用户对资源的访问控制问题,即判定用户对资源拥有怎样的访问权限，我们根据实际的业务需求基于RBAC模型进行组合和分离。 C端：以PMCAFF为例 PMCAFF因业务较简单，所以权限设置并不复杂；大部分C端产品权限设计都会涉及登录和不登录两种状态，对应也就是拥有的操作权限的异同了。 B端：以TAPD、蓝湖为例 TAPD使用了RBAC模型中的用户-权限，并未加上角色这个概念，但其拓展了用户组的概念。 这就是基于RBAC模型结合自身实际业务的延伸方案。 如下图： 蓝湖作为设计师切图管理工具，便捷设计师切图与开发人员之间的沟通，其权限设计虽不复杂，但使用了RBAC模型中的用户-角色-权限这组经典的三元组合：用户-角色-权限，但它的设计也是经过变形而来，为了操作简便，直接设定好角色和权限之间的关联：如编辑者（编辑画布、管理设计图、批注） 用户扩展为用户组或增加用户组的概念：如用户属于设计组，这个组的权限可能有10个，对应其中可能涉及用户角色（职位高低）有所增减，所以在大型公司会设用户组，或直接像TAPD一样使用组来配合权限管理。 备注：这个用户组也可能叫做岗位，是某一类的集合，所以不要纠结名字。 权限-权限组：如专注OA20多年的泛微集团，会将权限细分到不能细分的点，然后由管理员根据自身业务需求进行配置权限组，进而关联对应的角色或者用户，如下图： 1.云计算环境下RBAC模型的研究与设计_翟馨沂 2.： 君临天下夜未央 -RBAC权限模型简介