RBAC in depth & a practical way of microservice API authorization
原文链接：https://blog.csdn.net/zwk626542417/article/details/46726491 RBAC是Role-BasedAccess Control的英文缩写，意思是基于角色的访问控制。RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组，也就是“Who对What(Which)进行How的操作，也就是“主体”对“客体”的操作，其中who——是权限的拥有者或主体（如：User、Role），what——是资源或对象（Resource、Class) RBAC其实是一种分析模型，主要分为：基本模型RBAC0（Core RBAC）、角色分层模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）。 RBAC2: 案例： 先大概解释下我们的业务，我们做的是教育行业高校云平台，每个学校都可以在我们平台进行注册，注册完成后可以享受一些基础的服务，当然了不同级别的用户享受的基础服务是不同的，这些基础的服务包括新生注册管理、基础系统管理、考试系统管理、评教系统管理等模块，每个模块都相当于一个子系统，每个子系统都有各自的功能，每个功能也都有各自的相关的页面，而所有的子系统、页面以及页面上的功能按钮都是需要我们权限进行管理，所以我们的权限管理相对来说任务也是比较繁重的。 许可我一般称它为权限，它包括控制对象和操作，控制对象一般为资源，包括菜单、页面、文件等资源，而操作一般包括增删改查等，图中“系统操作”就是操作，“菜单信息”就是控制对象； 菜单信息中的每个菜单都会有增删改查等操作，所以菜单信息与系统操作是一对多的关系。 我们给角色授予权限时，授予就是颗粒最小的权限，所以我们将系统操作权限授予某些角色。一个角色可以拥有多个系统操作，一个系统操作同样也可以属于多个角色，所以系统操作和角色为多对多的关系。 进一步的细化深化： 完整的RBAC模型： Microservices API RBAC model: 如果把微服务化后的所有api接口都定义为上文的Resources，那么我们可以看到这么一个情况。案例： Authorization on API gateway: Authorization on microservice itself: Solution…