web应用的一配置实例应用场景：cas服务部署在192.168.7.115

一个配置示例

应用场景：cas服务部署在192.168.7.115，为web应用，访问地址为：:8443 /cas/。 web1应用位于192.168.7.90，访问地址为：8081/web1，web2应用位于192.1690，访问地址为：:8082/web2。 web1 和 web2 通过 cas 服务实现 SSO 功能。浏览器位于本地 localhost。

cas server: 172.16.52.35启动8443端口，需要配置证书

web1: 172.@ >16.52.35

主机配置：172.16.52.35cas.mycompany.com

web.xml 中的配置：

casServerUrlPrefix

:8443/cas/

服务器名称

172.16.52.35:8081

CAS 身份验证过滤器

org.jasig.cas.client.authentication.AuthenticationFilter

casServerLoginUrl

:8443/cas/login

CAS 验证过滤器

org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter

CAS 身份验证过滤器

/*

CAS 验证过滤器

/*

需要添加JDK启动参数（验证需要的CAS服务器证书）：

-Djavax.net.ssl.trustStore=/home/yz/web1/conf/cas-client-trust-cert.jks

-Djavax.net。 ssl.trustStorePassword=casclient!@#

web2: 172.16.52.35

主机配置：172.16.52.35cas.mycompany.com

web.xml 中的配置：

和web1中web.xml中的配置一样，只是serverName属性的值变成了192.168.7.90:8082

需要添加JDK启动参数（需要验证CAS服务器证书）：

-Djavax.net.ssl.trustStore=/home/yz/web2/conf/cas-client-trust-cert.jks

-Djavax.net.ssl.trustStorePassword =casclient!@#

注意：

1 casServerLoginUrl参数的值是cas服务器登录界面的值。 Web 应用程序中的 cas 客户端将在身份验证期间重定向到 cas 服务器。重定向的 url 是 casServerLoginUrl。因为是重定向的cas登录成功之后跳转的路径，所以浏览器所在的机器要配置cas服务器的域名。

2 casServerUrlPrefix参数的值是cas服务的访问地址。 cas客户端验证ticket时，需要访问cas服务的/serviceValidate接口。使用的 url 是 ${ casServerUrlPrefix }serviceValidate。因为客户端web应用需要验证cas证书，所以证书的cn字段的值必须和casServerUrlPrefix中设置的cas server一致。域名相同，在web应用服务器上配置了cas服务的访问域名。

2 serverName参数，cas客户端会用来生成service参数，cas服务器通过认证和ticket验证后会重定向到web应用，重定向的url就是service参数的值。 serverName参数可以是IP也可以是域名，只要浏览器可以访问即可。

CAS简介

CAS官网：

CAS主要文件：

CAS官网介绍图

主要原理：当用户第一次访问CAS服务的客户web应用时（访问URL::8081/web1），部署在客户web应用的cas AuthenticationFilter会拦截这个请求，生成服务参数，然后重定向到CAS服务的登录界面，url为：8443/cas/login?service=http%3A%2F%2F192.168. 7.90%3A8081%2Fweb1%2F，鉴权成功后，CAS服务器会生成一个鉴权cookie，写入浏览器，并将cookie缓存在服务器本地，CAS服务器也会生成根据服务参数生成一个ticket，ticket会保存到服务器并添加到url中，然后将请求重定向回客户端web应用，url为：8081/web1/?ticket=ST-5 -Sx6eyvj7cPPCfn0pMZuMwnbMvxpCBcNAIi6-20.此时客户端的AuthenticationFilter看到ticket参数，会被跳过，由T处理icketValidationFilter 后面，TicketValidationFilter 会使用httpclient工具访问cas服务的/serviceValidate接口，把ticket和service都传给这个接口，这个接口验证ticket的有效性，如果TicketValidationFilter验证成功消息，用户信息将被写入 Web 应用程序的会话中。至此SSO会话已经建立，以后用户在同一个浏览器中访问web应用时，AuthenticationFilter会读取会话中的用户信息，所以不会去CAS进行认证。如果AuthenticationFilter在本浏览器访问其他web应用时，无法读取session中的用户信息，就会去CAS登录界面进行认证，但随后CAS会读取浏览器，因此CAS不会要求用户登录登录页面，但会根据服务参数生成一个ticket，然后与web应用交互验证ticket。

第二个CAS客户端Fi过滤器的处理逻辑

1 身份验证过滤器

if(url中没有ticket参数&& session中没有TicketValidationFilter设置的断言对象){

response.sendRedirect(cas服务器的/login接口);//生成服务参数，添加到url后面

}

其他{

不处理

}

2 TicketValidationFilter

if(url中有ticket参数){

通过httpclient工具访问cas服务器的/serviceValidate接口，验证ticket的有效性，如果验证失败，则显示错误页面。如果验证成功，则会生成一个标识用户身份的断言对象并将其放置在会话中。

}

其他{

不处理

}

注意：

1 AuthenticationFilter 在前，TicketValidationFilter 在后。

2 身份验证过滤器：

1）url中没有ticket参数，session中也没有TicketValidationFilter设置的断言对象。这种情况说明用户还没有被认证，AuthenticationFilter会去做认证处理；

2）url中没有ticket参数，并且session中有TicketValidationFilter设置的assertion对象，表示用户已经认证成功，AuthenticationFilter不处理；

3）url中有ticket参数。这种情况下，用户已经认证成功，但是ticket需要经过TicketValidationFilter验证，AuthenticationFilter不处理。

3 TicketValidationFilter：只有当客户端调用cas服务器的/login接口并认证成功，并重定向回客户端时，url才包含ticket参数。在这种情况下cas登录成功之后跳转的路径，TicketValidationFilter 会进行处理。

三个CAS服务器的处理逻辑

CAS服务端一共暴露了7个接口，客户端通过访问这7个接口与服务端进行交互。这 7 个接口是：/login、/logout、/validate、/serviceValidate、/proxy、/proxyValidate、/CentralAuthenticationService。 /login是认证接口，/logout是出口接口，负责销毁认证cookie，/validate，/serviceValidate是验证票证的接口，其中/validate定义为CAS1.0，/serviceValidate是CAS2.由@>0定义，其中/serviceValidate返回xml格式的数据，/proxy和/proxyValidate是支持代理认证的接口，/CentralAuthenticationService接口用于与远程web服务交互。对于一般web应用的单点登录，/login、/logout、/serviceValidate这三个接口已经可以满足要求了。这些接口已经在 CAS 协议中定义，链接为： .下面详细介绍CAS的各个接口的实现。

/登录：

这部分登录过程要考虑到不同类型用户凭证的获取方案，以及来自客户端应用的service、gateway、renew参数的不同取值组合。为了实现流程的高度可配置性，CAS采用了Spring Web Flow技术。通过阅读CAS分发包中的login-webflow.xml、cas-servlet.xml、applicationContext.xml三个文件，找出了所有与login相关的组件，并绘制了其处理流程图。

CAS默认登录流程

第一次访问web应用程序进入

登录web1后，访问web1的资源（web1不启动会话），或者访问web2的资源

注意：

1：InitialFlowSetupAction：是流程的入口。使用 request.getContextPath() 的值来设置 cookie 的路径值。 cookie的路径值是在配置文件中定义的，但是这个Action负责将request.getContextPath()的值设置为cookie的路径值。这是在 cas 部署环境发生变化时，灵活设置cookie路径；将cookie的值和服务参数的值放入requestContext的flowscope中。

2：GenerateServiceTicketAction 该动作负责根据服务和 GTC cookie 值生成一个 ServiceTicket 对象。 ServiceTicket 的 ID 是返回给客户端应用程序的票证参数。如果成功创建 ServiceTicket，它将被转发到 WarnAction。如果创建失败，且 gateway 参数为 true，则直接重定向到客户端应用，否则需要重新认证。

3: viewLoginForm 这是 CAS 收集用户凭据的登录页面。 CAS提供的默认实现是/WEB-INF/view/jsp/simple/ui/casLoginView.jsp。

4：bindAndValidate对应AuthenticationViaFormAction的doBind方法，负责收集用户在登录页面输入的凭证信息（用户名、密码等），然后将这些信息封装到CAS内部的Credentials对象中当用户在 casLoginView.jsp 页面上单击提交时会触发此方法。

5：submit对应AuthenticationViaFormAction的submit方法。如果doBind方法执行成功，则触发submit方法。该方法负责调用centralAuthenticationService的grantServiceTicket方法完成认证工作。如果认证成功，则生成 TicketGrantingTicket 对象。在缓存中，TicketGrantingTicket的ID就是TGC Cookie的值。

6：warnCAS提供了一个功能：当用户在一个web应用中跳转到另一个web应用时，CAS可以跳转到一个提示页面，提示用户离开一个应用，进入另一个应用，用户可以选择。只有当用户在登录页面viewLoginForm上选中id=”warn”的复选框时，才能启用该功能。

WarnAction 检查用户是否启用了此功能。如果启用，它将被转发到 showWarnView。如果未启用，则会直接重定向到客户端应用程序。

7: SendTicketGrantingTicketAction 这个Action负责为响应生成一个TGC Cookie。 cookie的值为AuthenticationViaFormAction的submit方法生成的TicketGrantingTicket对象的ID。

8: viewGenerateLoginSuccess 这是CAS的认证成功页面。

/logout:（对应实现类org.jasig.cas.web.LogoutController）

处理逻辑：

1)删除Cookie

2)删除服务器上的TicketGrantingTicket对象（这个对象封装了cookie的值）

3）重定向到退出页面，有2个选项：

if(LogoutController的followServiceRedirects属性为true，且url中的service参数不为空){

重定向到服务参数标识的url

}

其他{

重定向到内置的casLogoutView（cas/WEB-INF/view/jsp/default/ui/casLogoutView.jsp），如果url中有url参数，url参数标识的链接会显示在 casLogoutView 页面上。

}

/serviceValidate:（对应实现类org.jasig.cas.web.ServiceValidateController）

处理逻辑：

如果service参数为空或者ticket参数为空，则转发到failureView(/WEB-INF/view/jsp/default/protocol/2.0/casServiceValidationFailure.jsp)

验证票证。以ticket为参数，去缓存中找到ServiceTicketImpl对象，如果能找到，并且没有过期，并且ServiceTicketImpl对象对应的服务属性对应服务参数，则验证通过。验证通过后，请求转发到casServiceSuccessView（cas/WEB-INF /view/jsp/default/protocol/2.0/casServiceValidationSuccess.jsp），如果验证失败，会转发到failureView .

四个认证相关概念及流程概念时序图

CAS认证处理时序图

类图

CAS认证类图

———本文来自dongdong_java的CSDN博客，全文地址请点击：