基本概念
什么是认证
进入移动互联网时代,大家每天都在刷手机,常用的软件有微信、支付宝、头条等,下边拿微信来举例子说明认证相关的基本概念,在初次使用微信前需要注册成为微信用户,然后输入账号和密码即可登录微信,输入账号和密码登录微信的过程就是认证。
系统为什么要认证?
认证是为了保护系统的隐私数据与资源,用户的身份合法方可访问该系统的资源。
认证 :用户认证就是判断一个用户的身份是否合法的过程,用户去访问系统资源时系统要求验证用户的身份信息,身份合法方可继续访问,不合法则拒绝访问。常见的用户身份认证方式有:用户名密码登录,二维码登录,手机短信登录,指纹认证等方式。
什么是会话
用户认证通过后,为了避免用户的每次操作都进行认证可将用户的信息保证在会话中。会话就是系统为了保持当前用户的登录状态所提供的机制,常见的有基于session方式、基于token方式等。
基于session的认证方式如下图:
它的交互流程是,用户认证成功后,在服务端生成用户相关的数据保存在session(当前会话)中,发给客户端的sesssion_id 存放到 cookie中,这样用户客户端请求时带上 session_id 就可以验证服务器端是否存在 session 数据,以此完成用户的合法校验,当用户退出系统或session过期销毁时,客户端的session_id也就无效了。
基于token方式如下图:
它的交互流程是,用户认证成功后,服务端生成一个token发给客户端,客户端可以放到 cookie 或 localStorage
等存储中,每次请求时带上 token,服务端收到token通过验证后即可确认用户身份。
什么是授权
还拿微信来举例子,微信登录成功后用户即可使用微信的功能,比如,发红包、发朋友圈、添加好友等,没有绑定银行卡的用户是无法发送红包的,绑定银行卡的用户才可以发红包,发红包功能、发朋友圈功能都是微信的资源即功能资源,用户拥有发红包功能的权限才可以正常使用发送红包功能,拥有发朋友圈功能的权限才可以使用发朋友圈功能,这个根据用户的权限来控制用户使用资源的过程就是授权。
为什么要授权?
认证是为了保证用户身份的合法性,授权则是为了更细粒度的对隐私数据进行划分,授权是在认证通过后发生的,控制不同的用户能够访问不同的资源。
授权: 授权是用户认证通过根据用户的权限来控制用户访问资源的过程,拥有资源的访问权限则正常访问,没有权限则拒绝访问。
授权的数据模型
如何进行授权即如何对用户访问资源进行控制,首先需要学习授权相关的数据模型。
授权可简单理解为Who对What(which)进行How操作,包括如下:
Who,即主体(Subject),主体一般是指用户,也可以是程序,需要访问系统中的资源。 What,即资源(Resource),如系统菜单、页面、按钮、代码方法、系统商品信息、系统订单信息等。系统菜单、页面、按钮、代码方法都属于系统功能资源,对于web系统每个功能资源通常对应一个URL;系统商品信息、系统订单信息都属于实体资源(数据资源),实体资源由资源类型和资源实例组成,比如商品信息为资源类型,商品编号 为001的商品为资源实例。
How,权限/许可(Permission),规定了用户对资源的操作许可,权限离开资源没有意义,如用户查询权限、用户添加权限、某个代码方法的调用权限、编号为001的用户的修改权限等,通过权限可知用户对哪些资源都有哪些操作许可。
主体、资源、权限关系如下图:
主体、资源、权限相关的数据模型如下:
主体(用户id、账号、密码、…)
资源(资源id、资源名称、访问地址、…)
权限(权限id、权限标识、权限名称、资源id、…)
角色(角色id、角色名称、…)
角色和权限关系(角色 id、权限id、…)
主体(用户)和角色关系(用户id、角色id、…)
主体(用户)、资源、权限关系如下图:
通常企业开发中将资源和权限表合并为一张权限表,如下:
资源(资源id、资源名称、访问地址、…)
权限(权限id、权限标识、权限名称、资源id、…)
合并为:
权限(权限id、权限标识、权限名称、资源名称、资源访问地址、…)
修改后数据模型之间的关系如下图:
RBAC
如何实现授权?业界通常基于RBAC实现授权。
基于角色的访问控制
RBAC基于角色的访问控制(Role-Based Access Control)是按角色进行授权,比如:主体的角色为总经理可以查
询企业运营报表,查询员工工资信息等,访问控制流程如下:
根据上图中的判断逻辑,授权代码可表示如下:
1 | if(主体.hasRole("总经理角色id")){ |
如果上图中查询工资所需要的角色变化为总经理和部门经理,此时就需要修改判断逻辑为“判断用户的角色是否是总经理或部门经理”,修改代码如下:
1 | if(主体.hasRole("总经理角色id") || 主体.hasRole("部门经理角色id")){ |
根据上边的例子发现,当需要修改角色的权限时就需要修改授权的相关代码,系统可扩展性差。
基于资源的访问控制
RBAC基于资源的访问控制(Resource-Based Access Control)是按资源(或权限)进行授权,比如:用户必须具有查询工资权限才可以查询员工工资信息等,访问控制流程如下:
根据上图中的判断,授权代码可以表示为:
1 | if(主体.hasPermission("查询工资权限标识")){ |
优点:系统设计时定义好查询工资的权限标识,即使查询工资所需要的角色变化为总经理和部门经理也不需要修改授权代码,系统可扩展性强。
基于Session的认证方式
认证流程
基于Session
认证方式的流程是,用户认证成功后,在服务端生成用户相关的数据保存在session
(当前会话),而发给客户端的 sesssion_id
存放到 cookie
中,这样用客户端请求时带上 session_id
就可以验证服务器端是否存在session
数据,以此完成用户的合法校验。当用户退出系统或session
过期销毁时,客户端的session_id
也就无效了。
下图是session认证方式的流程图:
基于Session的认证机制由Servlet规范定制,Servlet容器已实现,用户通过HttpSession的操作方法即可实现,如下是HttpSession相关的操作API。
方法 | 含义 |
---|---|
HttpSession getSession(Boolean create) | 获取当前HttpSession对象 |
void setAttribute(String name,Object value) | 向session中存放对象 |
object getAttribute(String name) | 从session中获取对象 |
void removeAttribute(String name) | 移除session中对象 |
void invalidate() | 使HttpSession失效 |
创建工程
本案例工程使用maven进行构建,使用SpringMVC、Servlet3.0实现。
创建maven工程
创建maven工程 security-springmvc,工程结构如下:
引入如下依赖如下,注意:
1、由于是web工程,packaging设置为war
2、使用tomcat7-maven-plugin插件来运行工程
1 |
|
Spring 容器配置
在config
包下定义ApplicationConfig.java
,它对应web.xml
中ContextLoaderListener
的配置
1 |
|
servletContext配置
本案例采用Servlet3.0无web.xml方式,的config包下定义WebConfig.java,它对应于DispatcherServlet配置。
1 |
|
加载 Spring容器
在init包下定义Spring容器初始化类SpringApplicationInitializer
,此类实现WebApplicationInitializer
接口,Spring容器启动时加载WebApplicationInitializer
接口的所有实现类。
1 | public class SpringApplicationInitializer extends |
SpringApplicationInitializer相当于web.xml,使用了servlet3.0开发则不需要再定义web.xml,ApplicationConfig.class对应以下配置的application-context.xml,WebConfig.class对应以下配置的spring-mvc.xml,web.xml的内容参考:
1 | <web‐app> |
实现认证功能
认证页面
在webapp/WEB-INF/views下定义认证页面login.jsp,本案例只是测试认证流程,页面没有添加css样式,页面实现可填入用户名,密码,触发登录将提交表单信息至/login,内容如下:
1 | <%@ page contentType="text/html;charset=UTF‐8" pageEncoding="utf‐8" %> |
在WebConfig中新增如下配置,将/直接导向login.jsp页面:
1 |
|
启动项目,访问/路径地址,进行测试
认证接口
用户进入认证页面,输入账号和密码,点击登录,请求/login进行身份认证。
(1)定义认证接口,此接口用于对传来的用户名、密码校验,若成功则返回该用户的详细信息,否则抛出错误异常:
1 | /** |
认证请求结构:
1 |
|
认证成功后返回的用户详细信息,也就是当前登录用户的信息:
1 | /** |
(2)认证实现类,根据用户名查找用户信息,并校验密码,这里模拟了两个用户:
1 |
|
( 3)登录Controller,对/login请求处理,它调用AuthenticationService完成认证并返回登录结果提示信息:
1 |
|
(4)测试
启动项目,访问/路径地址,进行测试
填入错误的用户信息,页面返回错误信息:
HTTP Status 500 - Internal Server Error
填入正确的用户信息,页面提示登录成功:
李四登录成功
以上的测试全部符合预期,到目前为止最基础的认证功能已经完成,它仅仅实现了对用户身份凭证的校验,若某用户认证成功,只能说明他是该系统的一个合法用户,仅此而已。
实现会话功能
会话是指用户登入系统后,系统会记住该用户的登录状态,他可以在系统连续操作直到退出系统的过程。
认证的目的是对系统资源的保护,每次对资源的访问,系统必须得知道是谁在访问资源,才能对该请求进行合法性拦截。因此,在认证成功后,一般会把认证成功的用户信息放入Session中,在后续的请求中,系统能够从Session中获取到当前用户,用这样的方式来实现会话机制。
(1)增加会话控制
首先在UserDto中定义一个SESSION_USER_KEY,作为Session中存放登录用户信息的key。
1 | public static final String SESSION_USER_KEY = "_user"; |
然后修改LoginController,认证成功后,将用户信息放入当前会话。并增加用户登出方法,登出时将session置为失效。
1 | /** |
(2)增加测试资源
修改LoginController,增加测试资源1,它从当前会话session中获取当前登录用户,并返回提示信息给前台。
1 | /** |
(3)测试
未登录情况下直接访问测试资源/r/r1:
匿名访问资源1
成功登录的情况下访问测试资源/r/r1:
李四访问资源1
测试结果说明,在用户登录成功时,该用户信息已被成功放入session,并且后续请求可以正常从session中获取当前登录用户信息,符合预期结果。
实现授权功能
现在我们已经完成了用户身份凭证的校验以及登录的状态保持,并且我们也知道了如何获取当前登录用户(从Session中获取)的信息,接下来,用户访问系统需要经过授权,即需要完成如下功能:
- 匿名用户(未登录用户)访问拦截:禁止匿名用户访问某些资源。
- 登录用户访问拦截:根据用户的权限决定是否能访问某些资源。
(1)增加权限数据
为了实现这样的功能,我们需要在UserDto里增加权限属性,用于表示该登录用户所拥有的权限,同时修改UserDto的构造方法。
1 |
|
并在AuthenticationServiceImpl中为模拟用户初始化权限,其中张三给了p1权限,李四给了p2权限。
1 | //用户信息 |
(2)增加测试资源
我们想实现针对不同的用户能访问不同的资源,前提是得有多个资源,因此在LoginController中增加测试资源2。
1 | /** |
(3)实现授权拦截器
在interceptor包下定义SimpleAuthenticationInterceptor拦截器,实现授权拦截:
1、校验用户是否登录
2、校验用户是否拥有操作权限
1 |
|
在 WebConfig
中配置拦截器,匹配/r/**
的资源为受保护的系统资源,访问该资源的请求进入SimpleAuthenticationInterceptor
拦截器。
1 |
|
(4)测试
未登录情况下,/r/r1与/r/r2均提示 “请先登录”。
张三登录情况下,由于张三有p1权限,因此可以访问/r/r1,张三没有p2权限,访问/r/r2时提示 “权限不足 “。
李四登录情况下,由于李四有p2权限,因此可以访问/r/r2,李四没有p1权限,访问/r/r1时提示 “权限不足 “。
测试结果全部符合预期结果。
小结
基于Session的认证方式是一种常见的认证方式,至今还有非常多的系统在使用。我们在此小节使用Spring mvc技术对它进行简单实现,旨在让大家更清晰实在的了解用户认证、授权以及会话的功能意义及实现套路,也就是它们分别干了哪些事儿?大概需要怎么做?
而在正式生产项目中,我们往往会考虑使用第三方安全框架(如 spring security,shiro等安全框架)来实现认证授权功能,因为这样做能一定程度提高生产力,提高软件标准化程度,另外往往这些框架的可扩展性考虑的非常全面。但是缺点也非常明显,这些通用化组件为了提高支持范围会增加很多可能我们不需要的功能,结构上也会比较抽象,如果我们不够了解它,一旦出现问题,将会很难定位。