权限篇:初探权限系统基本模型及 Spring Security 权限控制方案

本文探讨了基于角色的访问控制(RBAC)模型,包括用户、角色和权限三者的关系,阐述了在系统规模扩大时为何引入角色的概念。接着,文章介绍了在前后端分离架构下权限设计的注意事项,并展示了如何在Spring Security中实现URL级和方法级的权限控制。最后,讨论了权限赋予权限的时机,以及如何在UserDetailsService中填充用户权限信息。
摘要由CSDN通过智能技术生成

图1-1 文章脑图

Spring Security 主要的功能是 认证授权,认证系列篇基本完结,接下来将进入 Spring Security 的授权系列篇。

本文主要介绍 常规权限系统的基本设计模型以及 Spring Security 的权限控制方案,话不多说,Let’s Go !!!

常规权限系统设计模型

系统应用不做权限管控,就犹如在大街上裸奔一般。

至今为止最普及的权限模型是 RBAC模型,基于角色的访问控制(Role Based Access Control)。该模型主要含有3个实体,分别为: 用户角色权限

图1-2 RBAC模型

由模型图我们可以看出,三个实体分别是:用户、角色、以及权限;并且用户和角色之间是多对多的关系,角色和权限之间也是多对多的关系。

用户:发起操作的主体,比较常规的比如:系统的普通用户,管理员等。

角色: 拥有权限集的组合,用以连接用户和权限的桥梁;比如商城系统中管理员角色则有权限进行新增商品、下架商品等操作。

权限:用户可访问的资源,权限大体上可划分为:操作权限数据权限;操作权限是指页面上的功能按钮,例如:新增、删除、修改等。数据权限是指不同的用户在同一个页面下所看到的数据是不一样的。

可能有人会不理解,为什么在 用户权限之间多添加了一层 角色的概念,不能直接将权限给到具体的用户吗?在系统规模比较小的情况下确实可以这么做,但当系统的用户上来后,就变得难以维护了。

比如新增一个1000个用户,需要为新用户设置查看个人信息、编辑个人信息、修改密码等权限,将权限赋给用户的操作会产生将近3000条的记录;而如果引入 角色的概念,可以把查看个人信息、编辑个人信息、修改密码设置为 角色A,给1000个新增用户授予 角色A即可,这样1000个新增的用户都拥有了所需的权限,并且只产生1000条记录。

图1-3 对比图

权限模型基本介绍完毕,那该如何将模型落地到实践中呢?

随着前后端分离架构的逐步成熟,越来越多的系统在架构选型上都采取了前后端分离的架构;那么在前后端分离的架构下,权限设计有什么需要注意的地方呢?

在前后端分离的场景下,页面的跳转统一由前端控制,后端只负责提供数据。怎么友好的告诉前端某个用户是否拥有某项操作的权限呢?这里我们对 RBAC模型中的 权限实体做了略微的调整,引入 Rest风格,调整为 资源。正如我们所知,前端页面上的操作按钮会一一映射到后端的接口上,我们只需要在 资源表中维护相关接口的 URI即可。

基于上述结论,我们可以设计出最核心的几张数据库表:用户表、用户角色关系表、角色表、角色资源关系表、资源表

图 1-4 数据库模型

建表语句如下所示(省略其他信息,只关注权限相关):

CREATE TABLE `user_info` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `username` varchar(255) DEFAULT NULL COMMENT '用户名',
  `password` varchar(255) DEFAULT NULL COMMENT '密码',
  `enabled` tinyint(1) DEFAULT 1 COMMENT '0不可用 1可用',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COMMENT '用户表'


CREATE TABLE `role` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `name_en` varchar(64) NOT NULL DEFAULT '' COMMENT '角色名en',
  `name_cn` varchar(64) NOT NULL DEFAULT '' COMMENT '角色名cn',
  `enabled` tinyint(1) DEFAULT 1 COMMENT '0不可用 1可用',
【实例简介】 项目采用经典DDD架构(用沃恩.弗农大神的话,其实这是DDD-Lite)思想进行开发,简洁而不简单,实用至上,并且所写每一行代码都经过深思熟虑,符合SOLID规则! ####当前版本 3.0 alpha版(2017-2-7) 采用全新工作流,实现自定义表单处理; 2.0版(2016-10-31) 支持多流程模板; 增加Ace admin界面支持 秀外 输入图片说明 输入图片说明 输入图片说明 慧中 教科书级的分层思想,哪怕苛刻的你阅读的是大神级精典大作(如:《企业应用架构模式》《重构与模式》《ASP.NET设计模式》等),你也可以参考本项目。不信?有图为证,Resharper自动生成的项目引用关系,毫无PS痕迹! 输入图片说明 实用 符合国情的RBAC(基于角色的访问控制),可以直接应用到你的系统权限资源 菜单权限 经理和业务员登陆系统拥有的功能菜单是不一样的 按钮权限 经理能够审批,而业务员不可以 数据权限 A业务员看不到B业务员的单据 字段权限 某些人查询客户信息时看不到客户的手机号或其它字段 用户应用系统的具体操作者,我这里设计用户是可以直接给用户分配菜单/按钮,也可以通过角色分配权限。 角色为了对许多拥有相似权限的用户进行分类管理,定义了角色的概念,以上所有的权限资源都可以分配给角色,角色和用户N:N的关系。 机构树形的公司部门结构,国内公司用的比较多,它实际上就是一个用户组,机构和用户设计成N:N的关系,也就是说有时候一个用户可以从属于两个部门,这种情况在我们客户需求中的确都出现过。 ####系统工程结构: OpenAuth.Domain 系统领域层 OpenAuth.Repository 系统仓储层,用于数据库操作 OpenAuth.App 应用层,为界面提供接口 OpenAuth.Mvc 采用基于jquery与bootstrap的B-JUI界面 OpenAuth.UnitTest 单元测试 Infrastructure 通用工具集合 ####使用 管理员可直接在登录界面点击基于精典DDD的权限管理 - 点击以开发者账号登录登录; 普通应用账号使用:test(密码:test)登录; ####后续 更多狂野的功能,正在玩命加载中,敬请期待... 更多文档正在整理中.... 当然,如果你想学习完整的DDD框架,可以参考我的另一个项目(BestQ&A--开源中国推荐项目/集CQRS AES等DDD高级特性于一体的问答系统) 【实例截图】
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值