看一看Spring Security 原理分析

992 阅读4分钟

引言

在试题系统开发过程中,认证方式越来越完善,也对Spring Security有了更加深刻的理解。

本文,我们一起来领略Spring Security的设计原理。

原理

必备基础

Servlet是Java Web领域中的软件开发规范,Tomcat是实现Servlet规范的Java Web服务器。

package javax.servlet;

public interface Servlet {

    public void init(ServletConfig config) throws ServletException;

    public ServletConfig getServletConfig();

    public void service(ServletRequest req, ServletResponse res)
            throws ServletException, IOException;

    public String getServletInfo();

    public void destroy();
}

Servlet长这样,生命周期十分简单,初始化init、业务逻辑service、销毁destroy。

简单来说:我们根据Servlet接口开发我们的应用,服务器开发商根据Servlet接口开发Servlet服务器。

前端HTTP请求,Tomcat选择路由匹配的Servlet,如果已经实例化,直接调用service;如果未实例化,实例化后调用service,处理完之后返回响应。

图中示例的url统一采用小写,关于url大小写的问题,以下是结论,虽然有些url是大小写不敏感的,但是这使得表示唯一性变得困难,我们通常应该认为大小写是敏感的。

There may be URLs, or parts of URLs, where case doesn't matter, but identifying these may not be easy. Users should always consider that URLs are case-sensitive.

为了在Servlet前后执行其他逻辑,定义了Filter接口,在请求前后都会执行。

原理分析

从Spring Security官方文档摘抄的一张图:

Spring Security的原理其实就是通过Servlet中的Filter技术进行实现的,通过一系列内置的或自定义的安全Filter,实现接口认证与授权。

Spring Security官方也给出了默认Filter的执行顺序,先执行认证的过滤器,后执行授权的过滤器,其中就有我们常用的UsernamePasswordAuthenticationFilter、BasicAuthenticationFilter等等。

阅读源码一个Filter源码即可理解整个认证架构设计。

注:以下代码中部分无关代码已被删减。

public class BasicAuthenticationFilter extends OncePerRequestFilter {

     @Override
     protected void doFilterInternal(HttpServletRequest request,
               HttpServletResponse response, FilterChain chain) {
          try {
               /** 从请求中获取用户名密码信息 */
               UsernamePasswordAuthenticationToken authRequest = authenticationConverter.convert(request);
               /** 如果没有相关信息,说明不是此种认证方式,执行后续过滤器 */
               if (authRequest == null) {
                    chain.doFilter(request, response);
                    return;
               }
               /** 获取用户名 */
               String username = authRequest.getName();
               /** 判断该用户是否需要认证 */
               if (authenticationIsRequired(username)) {
                    /** 尝试使用 token 进行认证 */
                    Authentication authResult = this.authenticationManager
                              .authenticate(authRequest);
                    /** 认证成功,将认证结果置入上下文 */
                    SecurityContextHolder.getContext().setAuthentication(authResult);
                    /** 认证成功相关回调 */
                    this.rememberMeServices.loginSuccess(request, response, authResult);
                    onSuccessfulAuthentication(request, response, authResult);
               }
          }
          catch (AuthenticationException failed) {
               /** 认证失败,清空当前上下文信息 */
               SecurityContextHolder.clearContext();
               /** 认证失败相关回调 */
               this.rememberMeServices.loginFail(request, response);
               onUnsuccessfulAuthentication(request, response, failed);
               /** 如果需要忽略失败,则继续执行后续过滤器 */
               if (this.ignoreFailure) {
                    chain.doFilter(request, response);
               }
               /** 否则开始执行新的认证方案 */
               else {
                    this.authenticationEntryPoint.commence(request, response, failed);
               }
               return;
          }
          /** 本过滤器执行完毕,执行后续过滤器 */
          chain.doFilter(request, response);
     }
}

其实很简单是不是?

添加自定义认证逻辑

如果默认的验证方式不满足要求,要怎么添加自定义验证方式呢?其实只需要添加自定义的Filter即可。

就比如说常见的短信验证码登录方式:

默认不支持短信方式,我们可以在过滤器链中植入一个自定义的短信验证过滤器,认证成功后设置认证信息即可。

SecurityContextHolder.getContext().setAuthentication(authResult);

Reactive

这个是上个月遇到的问题,尝试了一下OAuth 2.0认证架构。

其实这个架构很普遍,许多项目都采用该种架构。只不过都是采用Spring Cloud Netflix Zuul + Spring Security Resource Server的实现。

这里我尝试将Zuul换成Spring Cloud Gateway,因为Zuul的阻塞IO在网关层面实在太影响性能了。

前面已经说了,Spring Security中的认证与授权方式是通过Servlet技术套装中的Filter实现的,Tomcat提供了Servlet的运行环境。

Spring Cloud Netflix Zuul集成Spring Boot Starter Web也就是默认的Tomcat实现网关,所以Zuul中是有Servlet的运行环境的。

而非阻塞的Spring Cloud Gateway基于Spring WebFlux框架,不支持Servlet,底层采用高性能的Netty服务器。

Spring WebFlux与Spring MVC的对比请看下图:

所以当Spring Security与Spring Cloud Gateway集成时,就会出错,Spring Security需要的Servlet环境没有被满足。

这也是之前对Reactive的理解不到位而引起的错误,WebFlux环境下,应该集成Spring Security Reactive,而非默认的Spring Security。

总结

经资料查阅,高性能的 Netty十分受各大互联网企业欢迎,Twitter、Facebook、苹果、微博都在使用Netty,具体Netty为什么更适合高并发?以后我们一起学习。

最后

上面都是自己整理好的!我就把资料贡献出来给有需要的人!顺便求一波关注。学习我们是认真的,拿大厂offer是势在必得的。想了解点击一下java交流群哦

[java交流群](想了解更多点一下哦)

原文链接:segmentfault.com/a/119000002…