CAS Java客户端登录相关过滤器的处理流程

首先了解一下CAS登录原理:

CAS结构中一般包含CAS服务器、应用服务器、客户端三个部分。客户端向应用服务器发出请求,由于未登录,会被跳转到CAS服务器登录。登录成功后跳转回应用服务器的登录前的URL,但是CAS服务器会给URL加上一个ticket参数。应用服务器拿着ticket去CAS服务器验证,验证成功后即加入一个session表示已登录,以后就不用再次登录了。

在web.xml配置中,AuthenticationFilter和TicketValidationFilter两个过滤器是负责处理登录流程的。

web.xml配置:

<filter>
	<filter-name>CAS Authentication Filter</filter-name>
	<filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class>
	<init-param>
		<param-name>casServerLoginUrl</param-name>
		<param-value>http://localhost:8080/cas/login</param-value>
	</init-param>
	<init-param>
		<param-name>serverName</param-name>
		<param-value>http://localhost:9999</param-value>
	</init-param>
</filter>
<filter-mapping>
	<filter-name>CAS Authentication Filter</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>
<filter>
	<filter-name>CAS Validation Filter</filter-name>
	<filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>
	<init-param>
		<param-name>casServerUrlPrefix</param-name>
		<param-value>http://localhost:8080/cas</param-value>
	</init-param>
	<init-param>
		<param-name>serverName</param-name>
		<param-value>http://localhost:9999</param-value>
	</init-param>
</filter>
<filter-mapping>
	<filter-name>CAS Validation Filter</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>

1、AuthenticationFilter

AuthenticationFilter中doFilter方法源码:

public final void doFilter(final ServletRequest servletRequest, final ServletResponse servletResponse, final FilterChain filterChain) throws IOException, ServletException {
        final HttpServletRequest request = (HttpServletRequest) servletRequest;
        final HttpServletResponse response = (HttpServletResponse) servletResponse;
        final HttpSession session = request.getSession(false);
        final Assertion assertion = session != null ? (Assertion) session.getAttribute(CONST_CAS_ASSERTION) : null;

        // 如果session中的CONST_CAS_ASSERTION(即"_const_cas_assertion_")不为空,则跳过此过滤器
        if (assertion != null) {
            filterChain.doFilter(request, response);
            return;
        }

        final String serviceUrl = constructServiceUrl(request, response);
        final String ticket = CommonUtils.safeGetParameter(request,getArtifactParameterName());
        final boolean wasGatewayed = this.gatewayStorage.hasGatewayedAlready(request, serviceUrl);

        // 如果ticket参数不为空,则跳过此过滤器
        if (CommonUtils.isNotBlank(ticket) || wasGatewayed) {
            filterChain.doFilter(request, response);
            return;
        }

        final String modifiedServiceUrl;

        log.debug("no ticket and no assertion found");
        if (this.gateway) {
            log.debug("setting gateway attribute in session");
            modifiedServiceUrl = this.gatewayStorage.storeGatewayInformation(request, serviceUrl);
        } else {
            modifiedServiceUrl = serviceUrl;
        }

        if (log.isDebugEnabled()) {
            log.debug("Constructed service url: " + modifiedServiceUrl);
        }

        final String urlToRedirectTo = CommonUtils.constructRedirectUrl(this.casServerLoginUrl, getServiceParameterName(), modifiedServiceUrl, this.renew, this.gateway);

        if (log.isDebugEnabled()) {
            log.debug("redirecting to \"" + urlToRedirectTo + "\"");
        }

        // 否则跳转到CAS Server登录页面
        response.sendRedirect(urlToRedirectTo);
    }

通过源码可以看出这个过滤器的处理流程:

如果session中包含name为"_const_cas_assertion_"的属性,也就是用户已经登录过了,则跳过此过滤器。

如果ticket参数不为空,即可能是登录后跳转回来的URL,则跳过此过滤器。(注意,AuthenticationFilter只判断ticket是否为空,并不做ticket合法校验,也就是随便输入一个ticket参数在URL中都可以通过此过滤器。而负责校验ticket的是第二个过滤器:TicketValidationFilter 。)

如果上面两个条件都不满足,也就是既没有"_const_cas_assertion_"的session又没有ticket参数,则跳转到XML配置的casServerLoginUrl,让用户到CAS Server上登录,并在URL加上一个参数service(即XML配置的serverName加上相对路径,用于登录成功后返回登录前的页面)。

下面来测试一下,web.xml先只配置一个过滤器,去掉其他过滤器:

在浏览器中输入地址http://localhost:9999/a/b/c并打开,会跳到登录页面,也就是XML中配置的casServerLoginUrl,并加上一个用于返回登录前页面的参数,这个参数由XML配置的serverName加上路径/a/b/c生成,即http://localhost:8080/cas/login?service=http://localhost:9999/a/b/c。再次页面输入用户名、密码登录,如果登录成功,则跳转到service参数指定的页面,并加上一个参数ticket,即http://localhost:9999/a/b/c?ticket=ST-12-1XGQRUtFnwtqQxdNLOdv-cas01.example.org。

这里可以再测试一下AuthenticationFilter是否校验ticket合法性。例如在浏览器中打开http://localhost:9999/a/b/c?ticket=123,其中ticket参数是随便写的,肯定不是合法的,但是访问可以直接进入页面,不再需要登录。也就是AuthenticationFilter只判断ticket是否为空,并不校验是否合法。

2、TicketValidationFilter

由于TicketValidationFilter、Cas20ProxyReceivingTicketValidationFilter都继承自AbstractTicketValidationFilter,下面看AbstractTicketValidationFilter中的doFilter方法源码:

    public final void doFilter(final ServletRequest servletRequest, final ServletResponse servletResponse, final FilterChain filterChain) throws IOException, ServletException {

        if (!preFilter(servletRequest, servletResponse, filterChain)) {
            return;
        }

        final HttpServletRequest request = (HttpServletRequest) servletRequest;
        final HttpServletResponse response = (HttpServletResponse) servletResponse;
        final String ticket = CommonUtils.safeGetParameter(request, getArtifactParameterName());

        // 如果ticket不为空,则校验此ticket,否则直接跳过此过滤器
        if (CommonUtils.isNotBlank(ticket)) {
            if (log.isDebugEnabled()) {
                log.debug("Attempting to validate ticket: " + ticket);
            }

            try {
                // 校验ticket,校验失败抛出异常
                final Assertion assertion = this.ticketValidator.validate(ticket, constructServiceUrl(request, response));

                if (log.isDebugEnabled()) {
                    log.debug("Successfully authenticated user: " + assertion.getPrincipal().getName());
                }

                request.setAttribute(CONST_CAS_ASSERTION, assertion);

                if (this.useSession) {
                    // 设置session中的CONST_CAS_ASSERTION(即"_const_cas_assertion_")属性
                    request.getSession().setAttribute(CONST_CAS_ASSERTION, assertion);
                }
                onSuccessfulValidation(request, response, assertion);

                if (this.redirectAfterValidation) {
                    log. debug("Redirecting after successful ticket validation.");

                    // URL去掉ticket参数并跳转
                    response.sendRedirect(constructServiceUrl(request, response));
                    return;
                }
            } catch (final TicketValidationException e) {
                response.setStatus(HttpServletResponse.SC_FORBIDDEN);
                log.warn(e, e);

                onFailedValidation(request, response);

                if (this.exceptionOnValidationFailure) {
                    throw new ServletException(e);
                }

                return;
            }
        }

        filterChain.doFilter(request, response);

    }

通过源码可以看出这个过滤器的处理流程:

如果有ticket参数,校验ticket是否合法(不合法则异常:org.jasig.cas.client.validation.TicketValidationException: CAS Server could not validate ticket)。

如果合法则在session加入"_const_cas_assertion_",并再次跳转,这次跳转主要就是去掉ticket参数,即从http://localhost:9999/a/b/c?ticket=ST-12-1XGQRUtFnwtqQxdNLOdv-cas01.example.org跳转到http://localhost:9999/a/b/c。(这样做有个好处就是如果用户F5刷新页面,由于已经没有ticket参数,不会再次去校验ticket,而同一个ticket只能使用一次,再次去CAS服务器校验会出现TicketValidationException异常。)

如果没有ticket参数,则直接跳过此过滤器(没有ticket参数的话就一定是session中包含"_const_cas_assertion_"的属性,否则连第一个过滤器AuthenticationFilter都无法通过)。

整理一下整个登录流程:

第一次请求应用服务器:

当用户第一次访问应用服务器的URL,由于session中没有"_const_cas_assertion_"且参数中没有ticket,会被AuthenticationFilter跳转到CAS服务器的登录页面。

第二次请求应用服务器:

在CAS服务器的登录页面成功登录以后,会跳转到应用服务器登录前的页面,但是加上了一个参数ticket。此次请求由于有ticket参数,通过了AuthenticationFilter,但是TicketValidationFilter会对ticket进行校验,校验成功后,会在session中加入"_const_cas_assertion_",再去掉ticket参数进行一次跳转。

第三次请求应用服务器:

此时由于session中已经有了"_const_cas_assertion_",会通过AuthenticationFilter,由于没有ticket参数,也通过了TicketValidationFilter,也就是可以正常显示出这个页面了。以后再请求应用服务器就和这次一样了,由于session包含"_const_cas_assertion_"即可正常访问。

作者:叉叉哥   转载请注明出处:http://blog.csdn.net/xiao__gui/article/details/38082761

CAS Java客户端登录相关过滤器的处理流程

时间: 2024-07-31 19:39:59

CAS Java客户端登录相关过滤器的处理流程的相关文章

java单点登录系统CAS的简单使用

转:http://blog.csdn.net/yunye114105/article/details/7997041 背景 有几个相对独立的java的web应用系统, 各自有自己的登陆验证功能,用户在使用不同的系统的时候,需要登陆不同的系统.现在需要提供一个统一的登陆/登出界面, 而不修改各个系统原来的登陆验证机制.于是采用单点登录系统CAS. 使用步骤 要使用单点登录,需要部署CAS系统, CAS服务端可以直接部署在tomcat下运行, 对于CAS服务端来说,所有要集成单点登录的web应用都是

呕心沥血的java复杂项目(包括自定义应用层协议、CS多线程、多客户端登录、上下线提醒等等)

建议大家先下源代码,导入到Eclipse,然后运行服务器和多个客户端,这样有个不错的体会.下载地址:http://download.csdn.net/detail/woshiwanghao_hi/7320927. 首先来看下整个系统的文件架构图: 系统是个基于UDP的聊天室,因为不能保持所有用户和聊天室的持续连接.同时为了保持数据传输的可靠性,就需要自定义应用层协议了. 程序大概的一个流程如下: 1.启动服务器,点击"start service",之后服务器及开始监听指定端口. 2.启

Springboot集成Shiro和Cas实现单点登录(服务端篇CAS5)

什么是单点登录? 先说一个需求场景,比如:一个企业的内部有N多个子系统,每个子系统都有一套自己的用户名和密码,那么企业的员工要登录N个子系统,这样一个员工 就要记住N个用户名和密码,就算各个子系统的用户名和密码都是统一的,登录每个子系统都要输入用户名和密码进行登录也是一个繁琐的操作过程,那么单点登录功能由此便应运而生了.单点登录(Single Sign On),简称为 SSO,是目前比较流行的企业业务整合的解决方案之一.SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应

java基础篇---Servlet过滤器

Servlet过滤器从字面上的字意理解为景观一层次的过滤处理才达到使用的要求,而其实Servlet过滤器就是服务器与客户端请求与响应的中间层组件,在实际项目开发中Servlet过滤器主要用于对浏览器的请求进行过滤处理,将过滤后的请求再转给下一个资源. 过滤器的基本概念 Filter是在Servlet 2.3之后增加的新功能,当需要限制用户访问某些资源或者在处理请求时提前处理某些资源的时候,就可以使用过滤器完成. 过滤器是以一种组件的形式绑定到WEB应用程序当中的,与其他的WEB应用程序组件不同的

CAS—修改默认登录页

1.  部署CAS-Server 本文以cas-server-3.4.11-release.zip为例,解压提取cas-server-3.4.11/modules/cas-server-webapp-3.4.11.war文件.然后,解压一个新的tomcat,我的目录为[H:\常用软件\03. Java\tomcat\apache-tomcat-6.0.33],然后把上面提取的文件copy到 [H:\常用软件\03. Java\tomcat\apache-tomcat-6.0.33\webapps

CAS—改动默认登录页

1.  部署CAS-Server 本文以cas-server-3.4.11-release.zip为例.解压提取cas-server-3.4.11/modules/cas-server-webapp-3.4.11.war文件.然后,解压一个新的tomcat,我的文件夹为[H:\经常使用软件\03. Java\tomcat\apache-tomcat-6.0.33],然后把上面提取的文件copy到 [H:\经常使用软件\03. Java\tomcat\apache-tomcat-6.0.33\we

开发 OpenAM Java 客户端

开发 OpenAM Java 客户端 在 Agent 安装完成之后,可以使用自带的 agentsample 应用登录.这里主要讲一下如何在 SSO 之后拿到 SSOToken,以及相关 Session 信息的获取.完整的代码在 Github. Agent 的安装在上一篇已经介绍,这里需要先配置一个 Policies,然后在客户端项目 web.xml 中加入 <filter> <filter-name>Agent</filter-name> <display-nam

java 拦截器、过滤器、监听器

转自:http://www.cnblogs.com/wangyuyu/archive/2013/07/02/3167354.html 一.理解Struts2拦截器 1. Struts2拦截器是在访问某个Action或Action的某个方法,字段之前或之后实施拦截,并且Struts2拦截器是可插拔的,拦截器是AOP的一种实现. 2. 拦截器栈(Interceptor Stack).Struts2拦截器栈就是将拦截器按一定的顺序联结成一条链.在访问被拦截的方法或字段时,Struts2拦截器链中的拦截

CAS 之自定义登录页实践

1. 动机 用过 CAS 的人都知道 CAS-Server端是单独部署的,作为一个纯粹的认证中心.在用户每次登录时,都需要进入CAS-Server的登录页填写用户名和密码登录,但是如果存在多个子应用系统时,它们可能都有相应风格的登录页面,我们希望直接在子系统中登录成功,而不是每次都要跳转到CAS的登录页去登录. 2. 开始分析问题 其实仔细想一想,为什么不能直接在子系统中将参数提交至 cas/login 进行登录呢? 于是便找到了CAS在登录认证时主要参数说明: service