技术分享 CAS单点登录 服务端配置 查看内容

cas入门之六:cas 登录流程(下)

老高 | 发布于 2017-05-05 12:25| 浏览()| 评论() | 收藏() | 点赞() | 打印

假设cas server服务地址:http://cas-server:8080/cas

cas client集成的应用地址:http://cas-client:8070/castest

cas client端:

1.用户在浏览器中访问http://cas-client:8070/castest/index.jsp

2.在castest应用判断用户没有登录,就重定向到cas server服务器,并且带有service查询参数

内容类似下面的内容:http://cas-server:8080/cas/login?service=http://cas-client:8070/castest/index.jsp

(这个cas client 的逻辑在此不详述,这个以后讨论)。

----------------------------------------------------------------------------------------

cas server 端:

1.tomcat启动,加载web.xml;

2.web.xml中加载

/WEB-INF/spring-configuration/*.xml

/WEB-INF/deployerConfigContext.xml  这些配置文件;

3.spring 自动加载cas-servlet.xml. 因为在web中配置一个名字为cas的servlet,在servlet2.5之后(好像是)会自动加载serlet名字-servlet.xml;

4.当用户访问 http://cas-server:8080/cas/login 则会调用这个在web.xml中配置的名字为cas的servlet;这个servlet调用spring dispatcher servlet,然后就进入了spring mvc;同时读取cas-servlet.xml文件;

5.调用cas-servlet.xml文件

为了从spring mvc中的请求转入spring web flow,需要进行二者的整合,所以需要配置

org.springframework.webflow.mvc.servlet.FlowHandlerMapping;

org.springframework.webflow.mvc.servlet.FlowHandlerAdapter;

具体的流程是:

客户端发送的请求,先会由 servlet 容器接收, servlet 容器会找到相应的应用程序,再根据 web.xml 的配置找到符合映射条件的 servlet 来处理。 

Spring Web MVC 中处理请求的 servlet 是 DispatcherServlet ,如果请求的路径满足 DispatcherServlet 的映射条件,

则 DispatcherServlet 会找出 Spring IoC 容器中所有的 HandlerMapping ,

根据这些 HandlerMapping 中匹配最好的 handler (一般情况下都是 controller ,即控制器)来处理请求。

当 Controller 处理完毕,一般都会返回一个 view (视图)的名字,DispatcherServlet再根据这个view的名字找到相应的视图资源返回给客户端。

搞清楚 Spring Web MVC 处理请求的流程后,基本上就可以明白要整合 Spring Web MVC 与 Spring Web Flow 所需要的配置了。

为了让客户端的请求变成执行某个 flow 的请求,要解决以下几个问题:

a.需要在某个 HandlerMapping 中配置负责处理 flow 请求的 handler (或 controller )

b.该handler (或 controller )要负责启动指定的 flow

c.flow 执行过程中以及执行完成后所涉及的视图应呈现给客户端

5.1.配置 flow executor

flowExecutor

FlowExecutor 是 Spring Web Flow 的一个核心接口,启动某个 flow,都要通过这个接口来进行。从配置角度来说,只要保证有个 FlowExecutor 就可以了, Spring Web Flow 的默认行为已经足够。

5.2配置FlowRegistry

FlowRegistry 是存放 flow 的仓库,每个定义 flow 的 XML 文档被解析后,都会被分配一个唯一的 id ,并以 FlowDefinition 对象的形式存放在 FlowResigtry 中。FlowRegistry 中注册的 flow 可能会有多个,但每个 flow 都会有 id ,没有配置的,也会有个默认值, FlowExecutor  就是通过 id 来找出要执行的 flow 。至于这个 id ,则是要由用户来指定的。在默认配置情况下,如果客户端发送了如下URL请求:

http://localhost:8080/cas/login

则从 Spring Web Flow 的角度来看,这个 URL 就表示客户想要执行一个 id 为“ login”的 flow ,于是就会在 FlowRegistry 中查找名为“ login”的 flow,由FlowExecutor负责执行。关于流(flow)的id的确定,有以下两种分配算法,如果base-path存在,那么流的id就是从base-path到流的定义文件之间的目录路径,比如说流的定义文件为/WEB-INF/views/hotels/booking/booking-webflow.xml,而base-path是/WEB-INF/views,

所以flow的id就为hotels/booking.如果base-path不存在或者流的定义文件就在base-path目录下,

那么这时flow的id就为流的定义文件名减去后缀(这里我们定义的后缀为-webflow.xml),

比如说我们的流定义文件叫login-webflow.xml,那么这时flow的id就为login。

现在进入了spring login-webflow.xml的配置文件,

6.login-webflow.xml

其中的图片参看 cas 入门之五:cas 登录流程(上)

因为此时是初次登录,所以用户没有cookie,故也就没有tgt,但是有service,所以就进入了登录页面

7.login-webflow.xml文件流转完成之后,会产生一个view视图,供用户前台显示,此时执行cas-servlet.xml中的builder;

builder--->viewFactoryCreator--->viewResolver     因为cas-servelet.xml引入了/spring-configuration/propertyFileConfigurer.xml文件,而propertyFileConfigurer.xml读取了/WEB-INF/cas.properties,所以在cas-servlet.xml中viewResolver的就可以读取到cas.properties中的属性值cas.viewResolver.basename 而cas.viewResolver.basename对应的值default_views,这样就对应default_views.properties;

8.进入classpath下的default_views.properties,

就可以找到相应的url页面;这样就顺利的进入了登录页面/WEB-INF/view/jsp/default/ui/casLoginView.jsp;

9.登录

在casLoginView.jsp中输入用户名,密码 点击登录,在login-webflow.xml的<view-state id="viewLoginForm"进行了数据绑定,当点击登录的时候进行form提交,

执行realSubmit这个authenticationViaFormAction中submit方法,而这个authenticationViaFormAction定义在cas-servlet.xml中;

10.进入到cas-servlet.xml中找到authenticationViaFormAction,从配置中可知它引用了

/WEB-INF/spring-configuration/applicationContext.xml中的centralAuthenticationService,

这个service是中心认证的service类,这个类是认证的中心类,基本上所有的认证配置都是围绕着这个类进行的,其中最重要的是它引用了/WEB-INF/deployerConfigContext.xml中authenticationManager,

authenticationManager是认证管理器,它管理着认证的基本流程;(关于认证管理器可参看cas 入门之四:认证管理器)

11.进入到deployerConfigContext.xml

找到authenticationManager,如何需要修改认证的方式以及认证的数据来源可以修改这个配置

12.其他的都不看了,现在我们只看当我们在

login-webflow.xml的realSubmit执行返回success时,下面的流程,

sendTicketGrantingTicket->serviceCheck->generateServiceTicket->warn->redirect

->postRedirectDecision->redirectView

<end-state id="redirectView" view="externalRedirect:${requestScope.response.url}" />

现在我们又回到了cas client客户端,返回的地址类似以下形式:

http://cas-client:8070/castest/index.jsp?jsessionid=122222222&ticket=ST-ssssssXXXXX

----------------------------------------------------------------------------------------------------------------------------

cas client端:

3.回到了cas client端

在本次回到应用端是重定向,此时cas server端完成了向用户浏览器写cookie的动作。至于cas client与cas server进行ticket校验以及返回用户信息,这个我们以后再讨论。


发表评论(对文章涉及的知识点还有疑问,可以在这里留言,老高看到后会及时回复的。)

表情