0101基础-认证授权-springsecurity

1 基础概念

1.1 认证

认证是为了保护系统的隐私数据和资源，用户的身份合法方可访问系统的资源。

认证：用户认证就是判断一个用户的身份身份合法的过程。用户去访问系统资源时，系统要求验证用户的身份信息，身份合法方可继续访问，不合法则拒绝访问。

常见认证方式：

• 用户名密码
• 二维码登录
• 手机验证码
• 指纹认证

1.2 会话

认证授权方案的产生根本原因应用层(WEB)通信基于HTTP协议,而HTTP协议是无状态的，我们无法通过HTTP访问确认用户是否登录。用户登录后，为了避免用户每次操作都进行认证，需要将用户信息保存。会话就是系统为了保持用户的登录状态提供的机制，常见的有基于Session-Cookie方式，基于token方式。

• Session-Cookie

基于Session-Cookie方式自行查阅相关文档。

缺点：服务器内存需要存储session信息，天然不支持分布式。

• token

token是就是令牌的意思。用户认证成功后，服务器端生成一个token发给客户端，客户端可以放到cookie或者localStorage等存储介质中。每次请求时携带token，服务器通过接收校验该token来确认用户身份。

1.3 jwt

jwt(json web token)是token的一种实现方式。本质也是加密的字符串。jwt相关知识可自行参考相关文档。

• Springboot + JWT-Token 生成与解析

1.4 授权

认证是为了保证用户身份的合法性，授权则是为了更细粒度的对隐私数据进行划分，授权不同的用户访问不同的资源。

授权：授权是用户认证通过后，根据用户的权限来控制用户访问资源的过程。

2 授权的数据模型

授权可简单理解为who对what进行how操作。

• who：即主体（Subject），主体一般值用户。
• what：即资源（Resource），如菜单，页面，按钮代码方法、系统商品信息等。系统菜单、页面、按钮、代码方法都属于系统功能资源，对于web系统每个功能资源通常对应一个URL；系统商品信息、订单信息、人员信息等属于实体资源（数据资源）。实体资源有资源类型和资源实例组成，比如商品信息为资源类型，编号为001的商品为资源实例。
• how：权限/许可（Permission），规定了用户对资源的操作许可，权限脱离资源没有意义，如用户添加权限、用户修改权限等。通过权限可知用户对那些资源都有那些操作许可。

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

主体、资源、权限相关的数据模型如下：

主体（用户id、账号、密码、…）

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

权限（权限id、权限标识、权限名称、资源id、…）

角色（角色id、角色名称、…）

北京市昌平区建材城西路金燕龙办公楼一层 电话：400-618-9090角色和权限关系（角色id、权限id、…）

主体（用户）和角色关系（用户id、角色id、…）

主体（用户）、资源、权限关系如下图：

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

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

权限（权限id、权限标识、权限名称、资源id、…）

合并为：

权限（权限id、权限标识、权限名称、资源名称、资源访问地址、…）

修改后数据模型之间的关系如下图：

3 RBAC

如何实现授权？业界通常基于RBAC实现授权。

3.1 基于角色的访问控制

RBAC基于角色的访问控制（Role-Based Access Control）是按角色进行授权，比如：主体的角色为总经理可以查

询企业运营报表，查询员工工资信息等，访问控制流程如下：

根据上图中的判断逻辑，授权代码可表示如下：

if(主体.hasRole("总经理角色id")){
查询工资
}

如果上图中查询工资所需要的角色变化为总经理和部门经理，此时就需要修改判断逻辑为“判断用户的角色是否是总经理或部门经理”，修改代码如下：

if(主体.hasRole("总经理角色id") || 主体.hasRole("部门经理角色id")){
查询工资
}

根据上边的例子发现，当需要修改角色的权限时就需要修改授权的相关代码，系统可扩展性差。

3.2 基于资源的访问控制

RBAC基于资源的访问控制（Resource-Based Access Control）是按资源（或权限）进行授权，比如：用户必须具有查询工资权限才可以查询员工工资信息等，访问控制流程如下：

根据上图中的判断，授权代码可以表示为：

if(主体.hasPermission("查询工资权限标识")){
查询工资
}

优点：系统设计时定义好查询工资的权限标识，即使查询工资所需要的角色变化为总经理和部门经理也不需要修改授权代码，系统可扩展性强

4 名词解析

4.1 SSO

单点登录（Single Sign On），简称为 SSO，是比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统;一次退出，退出已登录的全部应用系统。

4.2 CAS

CAS是Central Authentication Service的缩写，中央认证服务，一种独立开放指令协议。CAS 是 耶鲁大学（Yale University）发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。

简单来说CAS是SSO的一种实现方式。

4.3 联合登陆

联合登录，就是通过开放认证平台由第三方应用做身份担保，使用户可以活得本系统的相关权限，最常见的身份担保平台就是微信、QQ，当然阿里系的一些应用，支付宝，淘宝也可以为用户做身份担保。

• 联合登陆与单点登录

联合登录与单点登录区别主要就是： 联合登录是第三方提供身份担保，单点登录是通过统一认证中心确认登录状态。本质上单点登录的各个系统是完全互信的，联合登录是通过担保互信。

4.4 多端登录：同一账号不同终端登录

比如你在IOS移动端、MAC移动端、PC网页端、PC客户端登录QQ。

4.5 OAuth

OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAUTH是安全的。oAuth是Open Authorization的简写。

OAuth协议包含1.0和2.0版本，OAuth2.0授权验证流程更为简单安全，也是目前的主流方式，常见的厂商有支付宝、微信等。

参考文章：

• 一文讲透认证授权的那些事
• 一文彻底弄懂cookie、session、token
• 解读认证和授权 OAuth、SSO、CAS、JWT
• 认证、授权、鉴权、权限控制

参考视频：

• 黑马程序员Java进阶教程快速入门Spring Security OAuth2.0认证授权