cas学习.docx
- 文档编号:4707146
- 上传时间:2022-12-07
- 格式:DOCX
- 页数:18
- 大小:60.01KB
cas学习.docx
《cas学习.docx》由会员分享,可在线阅读,更多相关《cas学习.docx(18页珍藏版)》请在冰豆网上搜索。
cas学习
一CAS实现原理:
认证流程分析:
1:
用户第一次访问受保护的应用。
受保护的应用通过其中配置的统一认证过滤器队请求进行过滤,未发现在session中有特定的用户信息,也未发现有ST参数。
2:
应用系统将认定用户第一次进入受保护的系统中,重定向到统一认证系统中特定的路径。
通常该路径为http:
//统一认证IP:
端口/casserver/login
3:
统一认证系统判断用户在统一认证系统中是否登录过。
4:
如果没有登录过,则将用户定向到登录界面。
5:
用户在登录界面输入用户名和密码等信息,并进行提交。
6:
统一认证系统验证用户提交的凭证是否正确,如果正确,生成cookie形式的TGT(ticketgrantticket)和一个ST(serviceticket)。
并通过重定向跳回到受保护的系统中。
并且,将ST作为参数附加在URL后面。
7:
进入受保护系统中,请求经由统一认证过滤器进行过滤,发现虽然在session中不存在特定的用户信息,但是存在ST票据。
8:
有统一认证客户端持有ST票据通过http请求,发送到统一认证端进行认证票据的有效性。
9:
统一认证系统认证票据有效,相应用户信息到受保护系统。
10:
受保护系统获得用户信息,在session中设置特定的用户信息。
返回用户访问资源。
理解了CAS实现单点登录的原理之后,我们就来看一下CAS服务器端的整体结构:
分析web工程一般都是从web.xml文件开始进行分析的。
我们就先来看一下web.xml
首先是spring进行控制反转控制的配置文件。
通常使用过spring的开发人员应该对spring会比较了解,这里先不解释,以后的分析中,会对spring的两大特性IOC和AOP进行相应的分析。
/WEB-INF/spring-configuration/*.xml
/WEB-INF/deployerConfigContext.xml
第二部分是CAS的日志文件的配置。
这个方面以后将会作为一个知识点进行相对系统的分析。
log4j.xml
下面是CAS自身业务相关的重点了。
该filter主要是对进入CAS自身的接入系统管理的请求进行过滤的。
该过滤主要是采用springsecurity框架来处理的。
这会在将来也会作为一个知识点进行重点分析。
该过滤器是对请求的字符编码就行处理的过滤器。
相信大家都会很熟悉。
这里是对日志初始化相关的监听器。
将会在日志部分重点分析。
(其实不光是有日志,还有性能分析。
)
org.springframework.web.util.Log4jConfigListener
org.jasig.cas.web.init.SafeContextLoaderListener
这里是CAS进行统一认证的重点部分。
和认证相关的请求都是由这个servlet进行处理的。
org.jasig.cas.web.init.SafeDispatcherServlet
--Defaultto5minutesessiontimeouts-->
注意:
一个filter和一个servlet是可以对多个路径进行过滤的。
所以,遇到一个servlet处理多个路径的时候,最好不要尝试拦截所有请求路径,然后在servlet和filter中进行区分处理,这样效率是会很低的。
可以多些几个filtermapping,多些几个servletmapping。
虽然让web.xml看上去复杂很多,但效率会高出很多。
二在CAS中MVC的控制主要是使用的springMVC来实现的。
但是,在登录过程中,因为有点类似于工作流的性质,所以,采用了一个轻量级的工作流框架,就是spring的weflow。
下面,我们就CAS如何采用webflow控制登录流程进行分析。
想深入理解webflow工作原理的读者需要参考官方的webflow2.21版本的reference。
好了,话不多说,开始CAS认证流程之旅。
用户请求如何进入认证流程的
用户一开始输入http:
//localhost:
8080/CASServer的时候,默认是回去访问index.jsp的。
我们看一下index.jsp,里面的内容非常简单。
finalStringqueryString=request.getQueryString();
finalStringurl=request.getContextPath()+"/login"+(queryString!
=null?
"?
"+queryString:
"");
response.sendRedirect(response.encodeURL(url));
这里进行的处理就是将用户的请求重定向到CAS认证中心的/login路径下。
在上一章中,我们已经知道,该路径我们是由名为CAS的servlet,也就是org.jasig.cas.web.init.SafeDispatcherServlet进行处理的。
我们进入该servlet看一下他是如何进行处理的。
进入该servlet中,我们看到,他继承自HttpServlet,也就是说他只是一个普通的servlet。
该servlet持有一个DispatcherServlet属性delegate。
这同struts的处理方式如出一辙。
都是通过一个代理类来进行处理请求的。
该类的初始化也仅仅是调用代理类delegate的初始化。
Service函数很仅仅是调用delegate的service函数。
看来,DispatcherServlet类才是处理请求的关键类。
我们看到DispatcherServlet类的完整路径是
org.springframework.web.servlet.DispatcherServlet
这里,也就是将请求交给了springMVC处理了。
(关于springmvc,参考我其他的关于spring的源码分析文章)。
Webflow与SpringMVC集成
SpringMVC核心配置文件是cas-servlet.xml。
在该文件中,webflow将与springMVC进行集成。
这里有一个问题,就是spring何时开始加载cas-servlet.xml文件的呢?
原来,在初始化DispatcherServlet的时候,会自动加载servlet-name+“-servlet.xml”文件。
所以,cas-servlet.xml是自动加载的,不需要在配置文件进行配置。
(参见关于springMVC的文章)
交给springMVC之后,springMVC又将请求交给了webflow处理。
下面是webflow同springMVC的结合:
--根据工作流定义,生成一个执行器-->
flow-executorid="flowExecutor"flow-registry="flowRegistry"> flow-execution-attributes> always-redirect-on-pausevalue="false"/> flow-execution-attributes> flow-executor> --注册一个工作流id是子路径为flow入口对login的请求交由login-webflow.xml定义的处理器进行处理--> flow-registryid="flowRegistry"flow-builder-services="builder"> flow-locationpath="/WEB-INF/login-webflow.xml"id="login"/> flow-registry> flow-builder-servicesid="builder"view-factory-creator="viewFactoryCreator"expression-parser="expressionParser"/> 在该文件中,我们可以看到上面的配置项。 这就是将webflow框架作为springMVC的一个节点来进行配置。 webflow: flow-registry节点就是注册了一个webflow流程,该流程的入口,也就是ID=“login”。 这样,交给springMVC的请求路径如果是login的,则有springMVC交给webflow处理。 在webflow中,会定义一些视图,这些视图都是以view=”XXX”的形式存在的。 那么XXX又是如何找到对应的页面呢? ? 看flow-builder-services节点,我们会发现有个view-factory-creator属性,该属性就定义了视图解析工厂。 该视图解析工厂是由视图解析器组成的。 这里只定义了一个视图解析器,就是viewResolvers。 该视图解析器是springFramework中的ResourceBundleViewResolver的一个实例,该类可以通过basenames属性,找到value值对应的properties属性文件,该文件中式类似ke=values类型的内容,正是该文件将jsp文件映射成视图名称。 至此,springMVC与webflow已经集成完毕。 Webflow配置文件及源码分析 在WEB-INF文件夹下的login-webflow.xml是登陆流程的主要配置文件。 在该文件中,定义了用户登录的整个处理流程。 首先,配置文件中的on-start标签定义了用户第一次进入流程中的预处理动作。 该标签对应spring中的id为initialFlowSetupAction的bean。 查看该bean(InitialFlowSetupAction)的代码。 该类需要继承自AbstractAction,AbstractAction方法是org.springframework.webflow.action包中的类。 是webflow中的基础类。 该类中的doExecute方法是对应处理业务的方法。 就犹如servlet中的service方法一样。 该方法的参数是RequestContext对象,该参数是一个流程的容器。 该方法从request中获取TGT,并且构建一个临时的service对象(不同域注册的service,详情见接入系统管理)。 并且,将TGT和service放在FlowScope作用域中。 流程的初始化完毕之后,就开始一系列的判断了。 也就是进入decision-state节点。 这些节点是依次执行的。 --检查flow中是否存在TGT如果存在,存在进入hasServiceCheck,为空进入gatewayRequestCheck--> --主要是CS结构使用gatewat,暂时不研究--> --存在TGT,说明用户已经登陆,测试flow中service是否为空,不为空,进入renewRequestCheck,为空,进入viewGenericLoginSuccess--> =null"then="renewRequestCheck"else="viewGenericLoginSuccess"/> -- 用户已经登陆,且请求参数中存在service判断请求中是否存在'renew'参数,如果renew参数为空或者没有内容,那么,进入viewLoginForm,否则进入generateServiceTicket renew参数和gateway参数不兼容。 renew参数将绕过单点登录。 也就是说即使用户登录了,还将要求用户登录。 (等你妹啊,人家都登录了,凭什么还要让人家再登录一次) -->
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- cas 学习