Spring Security（04）——认证简介

最新推荐文章于 2024-10-13 19:37:30 发布

iteye_13139

最新推荐文章于 2024-10-13 19:37:30 发布

阅读量110

点赞数

分类专栏： spring Security 文章标签： Spring Security 认证过程 ExceptionTranslationFilter SecurityContextHolder

spring Security 专栏收录该内容

20 篇文章 2 订阅

订阅专栏

认证简介

1.1 认证过程

1.2 Web应用的认证过程

1.2.1 ExceptionTranslationFilter

1.2.2 在request之间共享SecurityContext

1.1 认证过程

1、用户使用用户名和密码进行登录。

2、Spring Security将获取到的用户名和密码封装成一个实现了Authentication接口的UsernamePasswordAuthenticationToken。

3、将上述产生的token对象传递给AuthenticationManager进行登录认证。

4、AuthenticationManager认证成功后将会返回一个封装了用户权限等信息的Authentication对象。

5、通过调用SecurityContextHolder.getContext().setAuthentication(...)将AuthenticationManager返回的Authentication对象赋予给当前的SecurityContext。

上述介绍的就是Spring Security的认证过程。在认证成功后，用户就可以继续操作去访问其它受保护的资源了，但是在访问的时候将会使用保存在SecurityContext中的Authentication对象进行相关的权限鉴定。

1.2 Web应用的认证过程

如果用户直接访问登录页面，那么认证过程跟上节描述的基本一致，只是在认证完成后将跳转到指定的成功页面，默认是应用的根路径。如果用户直接访问一个受保护的资源，那么认证过程将如下：

1、引导用户进行登录，通常是重定向到一个基于form表单进行登录的页面，具体视配置而定。

2、用户输入用户名和密码后请求认证，后台还是会像上节描述的那样获取用户名和密码封装成一个UsernamePasswordAuthenticationToken对象，然后把它传递给AuthenticationManager进行认证。

3、如果认证失败将继续执行步骤1，如果认证成功则会保存返回的Authentication到SecurityContext，然后默认会将用户重定向到之前访问的页面。

4、用户登录认证成功后再次访问之前受保护的资源时就会对用户进行权限鉴定，如不存在对应的访问权限，则会返回403错误码。

在上述步骤中将有很多不同的类参与，但其中主要的参与者是ExceptionTranslationFilter。

1.2.1 ExceptionTranslationFilter

ExceptionTranslationFilter是用来处理来自AbstractSecurityInterceptor抛出的AuthenticationException和AccessDeniedException的。AbstractSecurityInterceptor是Spring Security用于拦截请求进行权限鉴定的，其拥有两个具体的子类，拦截方法调用的MethodSecurityInterceptor和拦截URL请求的FilterSecurityInterceptor。当ExceptionTranslationFilter捕获到的是AuthenticationException时将调用AuthenticationEntryPoint引导用户进行登录；如果捕获的是AccessDeniedException，但是用户还没有通过认证，则调用AuthenticationEntryPoint引导用户进行登录认证，否则将返回一个表示不存在对应权限的403错误码。

1.2.2 在request之间共享SecurityContext

可能你早就有这么一个疑问了，既然SecurityContext是存放在ThreadLocal中的，而且在每次权限鉴定的时候都是从ThreadLocal中获取SecurityContext中对应的Authentication所拥有的权限，并且不同的request是不同的线程，为什么每次都可以从ThreadLocal中获取到当前用户对应的SecurityContext呢？在Web应用中这是通过SecurityContextPersistentFilter实现的，默认情况下其会在每次请求开始的时候从session中获取SecurityContext，然后把它设置给SecurityContextHolder，在请求结束后又会将SecurityContextHolder所持有的SecurityContext保存在session中，并且清除SecurityContextHolder所持有的SecurityContext。这样当我们第一次访问系统的时候，SecurityContextHolder所持有的SecurityContext肯定是空的，待我们登录成功后，SecurityContextHolder所持有的SecurityContext就不是空的了，且包含有认证成功的Authentication对象，待请求结束后我们就会将SecurityContext存在session中，等到下次请求的时候就可以从session中获取到该SecurityContext并把它赋予给SecurityContextHolder了，由于SecurityContextHolder已经持有认证过的Authentication对象了，所以下次访问的时候也就不再需要进行登录认证了。