深入分析tomcat and spring boot security and cas

SilasArchibald 发布于5月前 •最后由 ctolib4月前回复 阅读207次
2 条评论

前言

本文从一个web请求如何到达服务器,请求经历了哪些过程,最后是如何通过我们的授权验证(用cas认证举例),通过一步一步解析整个过程,同时给出相对应的类图和时序图来方便理解,最后做一个总的概括来进一步加强理解。本文的内容来自对源码的理解,如果有不正确的地方,可以在下方留言,我会及时修改,谢谢。阅读本文大约90分钟。

目录

  • 1 tomcat部分
  • 1.1 tomcat的类图结构
  • 1.2 tomcat的启动
  • 1.3 tomcat的请求
  • 1.4 StandardContext的reload过程(tomcat热部署)
  • 2 spring boot
  • 2.1 spring boot的启动
  • 2.2 spring boot的请求
  • 3 cas
  • 3.1 spring security的安全认证
  • 3.2 认证流程
  • 3.3 cas的认证原理
  • 4 总结
  • 5 参考

一些前提知识

  1. cookie and session。
  2. cas认证原理。
  3. 假设本文的其他内容读者都有所了解,如果不知道可以自己google。

一 tomcat

1.1 tomcat的类图结构tomcat的结构关系就是一个Server包含多个Service,Service指向一个Container,Service和Container的连接通过Connector实现。tomcat的顶层接口是lifecycle、container,其中lifecycle控制所有子容器的生命周期,container是每个具体容器的抽象。

可以从startup.sh里面发现tomcat的入口是Bootstrap里面的main方法。 Catalina是Bootstrap的代理类来实现真正的启动逻辑。

Server,Service,Engine,Host,Context依次是包含关系。他们自身实现了特定的功能方法。

ContainerBase是一个抽象类,实现了所有容器类都用到的公共方法。

Connector是Service的委托实例,可以看到StandardService里面是一个Connector[]的数组,主要用于监听端口,接收外部的请求。

ProtocolHandler是Connector的委托实例,用于进行请求相对应的协议来进行后续的处理。

下面是主要类图的结构,从上到下的实现关系。 深入分析tomcat and spring boot security and cas

1.2. tomcat的启动tomcat的启动主要分为容器的init和start两个部分。每个过程都是通过父容器先初始化,然后逐个通过for循环来初始化子容器,中间还包含一些相关的事件出发。

下面是从Bootstap到Pipeline启动的过程 深入分析tomcat and spring boot security and cas 我们通常的web.xml的解析就是在StanderdContext的start里面实现的,通过委托给ContextConfig解析所有的元素初始化Context变量。 下面是从Pipeline到Servlet的过程 深入分析tomcat and spring boot security and cas 1.3. tomcat的请求 当我们通过浏览器想服务器发送一个请求后,浏览器会帮我们生成一个http的报文,最终通过tcp发送到我们的服务端的监听端口,服务端监听到端口[connector]有数据进来便会从线程池里面选着一个线程来处理,然后把数据交给tomcat的对应Processor来处理,这里就是http11Processor来解析报文头,然后交给CoyoteAdapter,CoyoAdapter通过Mapper类进行Engine的选择,最后把request交给匹配的Engine来处理。从Engine到Wrapper的调用链路就是一个连续的过程[Pipeline的责任链模式]。最后由Wrapper交给fiIter及servlet进行处理。整个过程就是下面的时序图的流程。 深入分析tomcat and spring boot security and cas 深入分析tomcat and spring boot security and cas 1.4. StandardContext的reload过程 当我们设置了tomcat的server.xml里面的context的reloadable为true时,war被修改后,容器就监听到class文件有变更,首先就是把Context的状态改为暂停,这时候拒绝执行外部的访问,然后依次的停止servlet、filter、contextlistener,接着是WebappClassLoader进行class的重新加载,最后就是依次的init、start。下面是完整的流程图。 深入分析tomcat and spring boot security and cas

二 spring boot

2.1. spring boot 启动过程spring boot启动的过程和spring启动过程类似,只是在refresh(context)里面增加了embededtomcat的启动过程。spring自身的启动这里不讲述,下面主要是spring里面是如何启动embededtomcat的。关键点就是在初始化applicationcontext的时候通过EmbeddedServletContainerFactory来启动Tomcat,然后依次设置Tomcat需要的各种参数,最后把当前的context添加到tomcat里面,当前的context已经包含了在spring里面注册的filter以及filter,这个过程和上面的独立tomcat服务的启动顺序是相反的,但是实质是一样的。下面是主要的过程图及相关的代码注释。

深入分析tomcat and spring boot security and cas

tomcat的类结构和embededTomcat的类的对应关系。

深入分析tomcat and spring boot security and cas 2.2. spring boot的请求过程 和tomcat的请求过程一致,这里重点讲述下Filter的过程,因为后面主要是围绕security来进行的。filter的过程就是通过filterChain来进行的,这里要注意一点的是filterChain的初始化是在第一次请求到来的时候做的,因为filterChain初始化后会放在org.apache.coyote.Request类的Note里面,后续的请求直接从request.getNotes(1)里面获取,这样不用每次request都创建filterChain。所有的filter在一个filters数组里面,直到所有的filter都进行了才会把请求交给servlet来处理,所以security的认证过程一定是在filter里面做的。 深入分析tomcat and spring boot security and cas

三 cas

3.1. spring security的安全认证spring security认证的体系结构的顶层接口是AuthencationManager,然后具体的认证过程是通过委托给一系列AuthenticationProvider来实现的。AuthenticationProvider提供了对具体认证需要的信息查询的接口,我们可以实现UserDetailService里面达到查询我们需要的目标数据。当认证过程成功后就会生成一个AuthenticationToken,这个token就代表了请求的安全凭证。token会放入SecurityContext里面,然后生成sessionId,httpsession的熟悉里面设置了springSecurityContxtKey的值为当前的SecurityContext,下次请求进来的时候通过sessionId查询到httpSession,然后通过httpSession和springSecurityContxtKey就能拿到对应的securityContext。

下面是authencation的类图结构。 深入分析tomcat and spring boot security and cas

3.2. 认证流程security的认证入口点是SecurityContextPersistenceFilter。首先尝试从ContextRepository里面获取,如果有的化直接把securitContext设置到当前的threadLocal里面;如果没有就继续执行后面的认证Filter来创建,这里举例交给UsernamePasswordAuthenticationFilter来处理,UsernamePasswordAuthenticationFilter通过调用DaoAuthenticationProvider来做具体的认证过程,DaoAuthenticationProvider又通过UserDetailService来从db里面查询用户名和密码,然后和当前的提交参数对比,如果一致就认证通过。下面是完整的流程图。

深入分析tomcat and spring boot security and cas 3.3. cas的认证原理 首先了解几个概念,cas client就是我们的应用服务,cas server是实现cas认证的服务器。浏览器就是我们发起请求的地方。当我们通过浏览器向cas server发起请求,首先会通过authencationFilter来处理请求,authencationFilter发现没有cas票据,会重定向到cas server,如果之前没有登陆过cas server就会出现提示输入用户名密码,这时候cas server会生成TGT、ST、TGC,然后在重定向到cas client,后面的认证逻辑就交给CasAuthencationFilter来处理。 下面是请求的流程图。 深入分析tomcat and spring boot security and cas 深入分析tomcat and spring boot security and cas

CasAuthencationFilter的认证是通过CasAutenticationProvider来实现的。CasAuthencationFilter拦截路径是通过我们设置的servcie的path来判断的。授权的关键点就是下面的userDetailsChecker.check(userDetails)这个方法,这个方法里面会通过ticketValidator来验证cas server提供的ST是否有效,具体过程是带上service和ticket参数,service值是当前应用的服务地址,ticket值就是cas server之前生成的st,请求的地址就是cas server,path是serviceValidate,请求发送到cas server后,cas server根据之前用户访问生成的TGT来匹配当前请求,如果匹配成功就返回一个报文,里面包含了cas:authenticationSuccess的标签,同时返回了当前的用户cas:user,这个标签的值一般是登陆用户的id,接下来CasAutenticationProvider会调用userDetailService服务,userDetailService我们通常会直接实现自己的逻辑,比如通过cas:user查询具体的用户信息来设置相应的权限等。最终生成一个CasAuthenticationToken,里面有principal、userDetails、credentials(就是cas server生成的st)等信息,然后这个token会添加到httpSession的属性里面。

下面是CasAutenticationProvider的类图结构。 深入分析tomcat and spring boot security and cas

四 总结

本文讲述了tomcat的启动以及请求过程、spring security的结构体系、cas的认证过程,由于每个部分的知识点都很广泛,不能面面俱到,只是抽取了部分内容进行重点讲述,更多的内容会在后面逐渐补充。本文写作的动机主要是处于个人对知识的总结,同时也希望能给看到这篇文章的同学一些帮助。我记得当时自己在做项目接入cas的时候,由于几个配置问题,花了不少的时间,最后总结下来是由于对知识点的掌握不到位造成的,最后慢慢把问题解决,然后逐步分析里面的实现逻辑,其实现在想来很多知识其实并不难,从开始的时候就进行一些有意义的思考然后解决问题将会事半功倍。现在自己总结了一个座右铭“不要把复杂的问题想的太简单,也不要把简单的问题想复杂”,希望这句话也能帮到你。

五 参考

查看原文: 深入分析tomcat and spring boot security and cas

  • beautifulduck
  • organicpanda
  • blackbird
  • 王飞@大连
  • 王飞@大连

    请问有清晰版的附图么? 基本上看不清楚类图的细节

    #1楼, 4月前 回复
  • ctolib
    #1楼 @王飞@大连 你可以查看文章的底部原文链接,有大图。
    #2楼, 4月前 回复
需要 登录 后回复方可回复, 如果你还没有账号你可以 注册 一个帐号。