专栏首页架构技术专栏Spring Cloud Security OAuth2.0 认证授权系列(一) 基础入门
原创

Spring Cloud Security OAuth2.0 认证授权系列(一) 基础入门

世界上最快的捷径,就是脚踏实地,本文已收录【架构技术专栏】关注这个喜欢分享的地方。

前序

最近想搞下基于Spring Cloud的认证授权平台,总体想法是可以对服务间授权,想做一个基于Agent 的无侵入的方式。

因为新版本的Spring Cloud Security 、 OAuth2.0 貌似改了些东西,说上网随便翻翻,但发现没有针对Spring Security OAuth2.0认证授权系统性的文章。

遂结合一些资料和自己的一些梳理,来搞一个认证授权系列,就当是一个总结了。

其实前面我也搞了几个关于认证授权的文章,但总感觉太零碎了,不成体系,没搞过 Security 、OAuth2.0、JWT的人会一脸懵逼。

这次准备再从头梳理下这方面的只是,逐步递进。尽量不搞长篇大论,看的脑阔疼,争取一篇一个点的推进。

话不多说,饭要一口口吃,基础的东西其实也很重要,那就从头来说吧。

基础概念

1、认证的概念

在这个移动时代,我们每天都在各种APP间切换着,比如抖音、淘宝、微信等,比如我们拿抖音来举例说明认证的一些基础概念。

比如我们在使用抖音前都需要进行注册吧,然后在输入用户名和密码(或验证码)来登录账号。

这里登陆的过程就是 认证

那为什么要认证?

认证,其实就是为了保护系统的资源,只有用户身份合法才可以访问资源。

认证 :用户认证就是判断一个用户的身份是否合法的过程,用户去访问系统资源时系统要求验证用户的身份信

息,身份合法方可继续访问,不合法则拒绝访问。

常见的用户身份认证方式有:

  • 用户名密码登录
  • 二维码登录
  • 手机短信登录
  • 指纹认证
  • 人脸识别

2、会话的概念

大家想想,如果我使用微信每点一个按钮都要我进行一次认证,那我岂不是要疯了。所以为了避免这种问题,在用户认证完成后可将用户信息保存在会话中。

会话其实就是系统保留了当前用户登录状态所提供的一种机制。

常见的会话方式:

  • 基于session
  • 基于token

基于session的认证方式:

1、用户认证成功,在服务端将用户信息保存在session中(目前很多为redis)

2、将sesssion_id返回给客户端并存入 cookie 中

客户端每次请求时带上session_id,服务端就会根据其进行用户合法性验证。当用户退出系统或session过期时,客户端的session_id也就失效了。

基于token的认证方式:

1、用户认证成功,在服务端会根据用户信息和某种加密手段生产一个token(如JWT)发给客户端

2、客户端将token存入 cookie 或 localStorage 中,在每次请求时带上token,服务端就可以根据token进行用户身份认证。服务端无需进行token存储,因为用户信息都包含在token中。

注意:

  • session的认证方式由Servlet规范定制,服务端需存储session,客户端需要支持 cookie(如不支持cookie就需要特殊处理)
  • token的认证方式不需要服务端存储token,并且不限制客户端的存储方式
  • 在现今的互联网时代,系统多为前后端分离的架构设计,所以基于token的方式更好点

3、授权的概念

我们那微信来举例,当用户登陆成功后就可以使用发朋友圈、添加好友、发红包等功能。

但此时如果我们没有绑卡,是无法使用发红包功能的,也就是说我们没有发红包的权限。

只有绑定银行卡的用户才可以发红包,也就是说此时的用户拥有了发红包的权限。

这个根据用户的权限来控制用户使用资源的过程就是授权 。

为什么要授权?

认证是为了确认用户的合法性,而授权是为了更细粒度的对数据进行划分,授权是发生在认证完成后的,用来控制不同的用户访问不同的资源。

授权: 授权是用户认证通过根据用户的权限来控制用户访问资源的过程,拥有资源的访问权限则正常访问,没有

权限则拒绝访问。

授权的数据模型

都知道写代码有设计模式,经过总结,授权也有其数据模型

其实也就是哪些用户,拥有哪些权限,可以访问哪些资源,如下图:

关于上图,我们可以抽象出几个关键点:

who 对what 进行 how 操作

who : 用户

what: 资源

how: 权限

例如上面,用户02 可以对商品信息01 进行修改操作,其实这也是一种经典的授权方案,后面我们再来细说

然后通过上图,可以抽象其中的关系,来帮助我们落地数据库表设计,来一个经典的:

授权方案

如何实现授权的设计?其实业界有几种常用方案:

  • ACL 访问控制列表,表达和执行能力都较弱
  • RBAC 基于角色的权限控制,表达能力有所欠缺,只能表达正向的访问控制,反向控制较难
  • ABAC 基于属性的权限控制,能较好地表达反向访问控制,但执行能力较差
  • PBAC 基于策略的权限控制,结合了RBAC 和 ABAC 的最佳特性,它能实现更多应用场景复杂且灵活的管理控制需求

其中ABAC和PBAC在互联网场景中很少使用,ACL是直接关系,RBAC是间接关系,所以我们来看下一般常用的RBAC

RBAC

RBAC权限模型(Role-Based Access Control), 基于角色的权限控制

在20世纪90年代期间,大量的专家学者和专门研究单位对RBAC的概念进行了深入研究,先后提出了许多类型的RBAC模型,其中以美国George Mason大学信息安全技术实验室(LIST)提出的RBAC96模型最具有系统性,得到普遍的公认。

RBAC认为权限的过程可以抽象概括为:判断【Who是否可以对What进行How的访问操作】这个逻辑表达式的值是否为True的求解过程。

RBAC模型的数据库建模

RBAC 将权限问题转换为Who、What、How的问题,其实根本就是用户通过角色进行权限关联。

一个用户可以拥有多个角色,一个角色又可以拥有多个权限。这样就构成了用户 - 角色 - 权限的授权模型。在模型中,用户和角色之间,角色和权限之间,一般是多对多关系,如图。

这里有个核心点,就是角色,可以理解为权限的集合体,是一种载体。比如论坛的版主、超级管理员等,版主可以管理对帖子进行管理,这就是权限。如果要给某个用户授予这些权限,只需要把角色赋予该用户就好了,而不需要和权限进行直接绑定。

进一步,增加权限组设计

而在实际应用过程中会发现,当用户量非常大的时候,如果我们要给每个用户进行授权那真是累到手抽筋啊。所以,这时候就需要给用户分组,分组后我们也可以直接给用户组进行授权。这时用户所拥有的权限,就是用户个人权限和用户组权限之和。

我们来看看进化后的模型:

再进一步,增加页面功能权限设计

在我们实现场景中,对功能模块的操作、菜单访问、按钮访问、文件上传等都可属于权限的范畴。

在有些权限设计中,会把功能操作作为一类,而把文件、菜单、页面元素等作为另一类,这样构成“用户-角色-权限-资源”的授权模型。

在做数据表建模时,可把功能操作和资源统一管理,也就是都直接与权限表进行关联,这样可能更具便捷性和易扩展性

比如这里我们有菜单、文件等功能,我们来看下权限表更新后的设计:

这里有几个核心点说一下:

通过权限表的权限类型字段,我们可以自有扩展自己的权限。比如MENU代表菜单权限、FILE代表文件权限,我们在扩展时只需要建一张权限XXX关联表就可以了。

这里权限表、菜单表、权限菜单关联表是1对1的关系,所以如果新增一个菜单就需要同时在三张表内插入记录。在设计时也可以省去关联表,直接叫权限表和菜单表进行关联,只是需要在权限表内增加一个记录菜单ID的字段,方便后面进行区分。

好了,到目前为止,基于RBAC的权限模型设计就完成了,来一个完整的设计图

后序

本章节属于针对于基础概念做了些铺垫,RBAC属于重点内容,也属于我们目前设计权限也会经常用到的一种模式。

至于RBAC的表设计,其实万变不离其宗,主要的还是搞清楚who、what、how。至于具体怎么实现就看你的业务需求了,没有完美的设计,只有不停的迭代。

后续计划,大概说下

  • Spring Cloud Security 使用
  • 和OAuth2.0怎么结合
  • 分布式系统的认证方案
  • 基于Spring CloudSecurity 实现分布式认证授权

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 何时用多线程?多线程需要加锁吗?线程数多少最合理?

    不知道大家有没有想过这个问题,就是什么时候我该使用多线程呢?使用多线程就一定会提升系统性能吗?

    架构技术专栏
  • 1000000 / 60S 的 RocketMQ 不停机,扩容,平滑升级!

    1、各业务系统持续迭代过程中,JDK、SpringBoot、RocketMQ Client 等框架也进行了升级,高版本的 RocketMQ Client 发送的...

    架构技术专栏
  • 每日一个知识点:什么时候会触发Full GC

    只是建议虚拟机执行 Full GC,但是虚拟机不一定真正去执行。不建议使用这种方式,而是让虚拟机管理内存。

    架构技术专栏
  • 工作记录一: 由权限引起的签约类目无法加载的问题的思路

    我们在遇到问题时, 可能解决的出发点不是在后端而是前端, 注意到前端的返回体中的内容, 能够帮助我们更好的解决bug

    时间静止不是简史
  • 用户、群组和权限

    Linux系统所采取的安全措施如下,用户登录系统时必须提供用户名和密码,以用户和群组来控制访问文件和其他资源,每个文件都属于一个用户并与一群文件相关,每个进程都...

    于小勇
  • 如何反编译小程序,亲测有效!

    微信小程序自诞生以来,高歌猛进,实现了很多的业务场景,也取代了APP的一些市场份额,现在各种微信小程序层出不穷,下面给大家介绍一下如何反编译小程序。

    越陌度阡
  • Python实现代码块儿折叠

    在python中方法和类都是可以折叠的,但是很多时候需要按照实现的功能将一部分代码折叠起来。

    砸漏
  • Linux特殊权限详解

    实际上Linux有12位权限,我们前面说的Linux权限都只说了常用的9位权限,剩下的特殊权限也经常被用来进行Linux提权,如果没有了解了的,可以移步之前的文...

    信安本原
  • Python全栈(三)数据库优化之5.MySQL自关联、外键与Python操作MySQL

    引入:省市区三级联动数据 导入外部.sql文件的数据: 从SQLyog选择文件导入并执行SQL语句,导入了三张表(省、市、县区)的数据。 读者需要练习使用...

    cutercorley
  • Flink DataSet编程指南-demo演示及注意事项

    Flink中的DataStream程序是对数据流进行转换的常规程序(例如,过滤,更新状态,定义窗口,聚合)。数据流的最初的源可以从各种来源(例如,消息队列,套接...

    Spark学习技巧

扫码关注云+社区

领取腾讯云代金券