【原创】CAS调研总结

最新推荐文章于 2019-09-03 15:15:00 发布

iteye_8413

最新推荐文章于 2019-09-03 15:15:00 发布

阅读量338

点赞数

分类专栏：开源研究—CAS 文章标签：应用服务器 Web 浏览器配置管理 JSP

本文链接：https://blog.csdn.net/iteye_8413/article/details/81798452

版权

开源研究—CAS 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

本篇文章是对JA-SIG CAS（v3.3）的初步调研总结。

一配置实例

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

cas 服务器： 192.168.7.115 启动8443 端口，需配置证书

web1 : 192.168.7.90

hosts 配置： 192.168.7.115 cas.mycompany.com

web.xml 里的配置：

<context-param>

<param-name>casServerUrlPrefix</param-name>

<param-value>https://cas.mycompany.com:8443/cas/</param-value>

</context-param>

<context-param>

<param-name>serverName</param-name>

<param-value>192.168.7.90:8081</param-value>

</context-param>

<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>https://cas.mycompany.com:8443/cas/login</param-value>

</init-param>

</filter>

<filter-name>CAS Validation Filter</filter-name>

<filter-class>

org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter

</filter-class>

</filter>

<filter-mapping>

<filter-name>CAS Authentication Filter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

<filter-mapping>

<filter-name>CAS Validation Filter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

JDK 启动参数需加上( 验证CAS 服务器证书的需要) ：

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

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

web2 : 192.168.7.90

hosts 配置： 192.168.7.115 cas.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!@#

本地：hosts 配置： 192.168.7.115 cas.mycompany.com

注：

1 casServerLoginUrl 参数的值是cas 服务器login 接口的值。web 应用里的cas client 在认证的时候会redirect 到 cas 服务器，redirect 的url 就是casServerLoginUrl ，因为是redirect ，所以浏览器所在机器要配置cas 服务器的域名。

2 casServerUrlPrefix 参数的值是cas 服务的访问地址。cas client 验证ticket 的时候，要访问cas 服务的/serviceValidate 接口，使用的url 就是${ casServerUrlPrefix }serviceValidate ，因为客户web 应用要验证cas 的证书，所以证书cn 字段的值必须和casServerUrlPrefix 里设置的cas 服务器的域名保持一致，并且在web 应用的服务器上配置cas 服务的访问域名。

2 serverName 参数，cas client 会用来生成service 参数，并且cas 服务器在认证通过、ticket 验证通过后，会redirect 到web 应用，redirect 的url 就是service 参数的值。serverName 参数可以是IP ，也可以是域名，只要保证浏览器能访问到即可。

二 CAS 简单介绍

CAS 官方网站： http://www.jasig.org/cas

CAS 的主要文档：

http://www.ja-sig.org/wiki/display/CASUM/Home

http://www.jasig.org/cas/cas1-architecture

http://www.jasig.org/cas/cas2-architecture

http://www.jasig.org/cas/protocol/

http://www.ja-sig.org/wiki/display/CASUM/Demo

CAS 官方网站上的介绍图

主要原理：用户第一次访问一个CAS 服务的客户web 应用时（访问URL ：http://192.168.7.90:8081/web1 ），部署在客户web 应用的cas AuthenticationFilter ，会截获此请求，生成service 参数，然后redirect 到CAS 服务的login 接口，url 为https://cas:8443/cas/login?service=http%3A%2F%2F192.168.7.90%3A8081%2Fweb1%2F ，认证成功后，CAS 服务器会生成认证cookie ，写入浏览器，同时将cookie 缓存到服务器本地，CAS 服务器还会根据service 参数生成ticket,ticket 会保存到服务器，也会加在url 后面，然后将请求redirect 回客户web 应用，url 为http://192.168.7.90:8081/web1/?ticket=ST-5-Sx6eyvj7cPPCfn0pMZuMwnbMvxpCBcNAIi6-20 。这时客户端的AuthenticationFilter 看到ticket 参数后，会跳过，由其后面的TicketValidationFilter 处理，TicketValidationFilter 会利用httpclient 工具访问cas 服务的/serviceValidate 接口, 将ticket 、service 都传到此接口，由此接口验证ticket 的有效性，TicketValidationFilter 如果得到验证成功的消息，就会把用户信息写入web 应用的session 里。至此为止，SSO 会话就建立起来了，以后用户在同一浏览器里访问此web 应用时，AuthenticationFilter 会在session 里读取到用户信息，所以就不会去CAS 认证，如果在此浏览器里访问别的web 应用时，AuthenticationFilter 在session 里读取不到用户信息，会去CAS 的login 接口认证，但这时CAS 会读取到浏览器传来的cookie ，所以CAS 不会要求用户去登录页面登录，只是会根据service 参数生成一个ticket ，然后再和web 应用做一个验证ticket 的交互而已。

二 CAS 客户端 Filter 的处理逻辑

1 AuthenticationFilter

if(url 中无ticket 参数 && session 中没有TicketValidationFilter 置的assertion 对象){

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

}

else{

不做处理

}

2 TicketValidationFilter

if(url 中有ticket 参数){

通过httpclient 工具访问cas 服务器的/serviceValidate 接口验证ticket 的有效性，验证失败，显示错误页面，验证成功，则生成标识用户身份的assertion 对象，放入session 。

}

else{

不做处理

}

注：

1 AuthenticationFilter 在前，TicketValidationFilter 在后。

2 AuthenticationFilter ：

1 ）url 中无ticket 参数，且session 中没有TicketValidationFilter 置的assertion 对象，这种情况说明用户还没有认证，AuthenticationFilter 会去做认证处理；

2 ）url 中无ticket 参数，且session 中有TicketValidationFilter 置的assertion 对象，这种情况说明用户已经认证成功，AuthenticationFilter 不做处理；

3 ）url 中有ticket 参数，这种情况说明用户已经认证成功，但还需要经TicketValidationFilter 去验证ticket,AuthenticationFilter 不做处理。

3 TicketValidationFilter ：只有客户端调用cas 服务器的/login 接口, 并成功认证，redirect 回客户端时，url 里才带有ticket 参数，在这种情况下，TicketValidationFilter 才做处理。

三 CAS 服务端的处理逻辑

CAS 服务端总共对外暴露了7 个接口，客户端通过访问这7 个接口与服务端交互，这7 个接口为：/login 、/logout 、/validate 、/serviceValidate 、/proxy 、/proxyValidate 、/CentralAuthenticationService 。/login 是认证接口，/logout 是退出接口，负责销毁认证cookie,/validate 、/serviceValidate 是验证ticket 用的接口，其中/validate 是CAS1.0 定义的，/serviceValidate 是CAS2.0 定义的，其中/serviceValidate 返回xml 格式的数据，/proxy 、/proxyValidate 是支持代理认证功能的接口，/CentralAuthenticationService 接口用于和远程的web services 交互。对于一般web 应用的单点登录来讲，/login 、/logout 、/serviceValidate 这3 个接口已经可以满足要求 。CAS 协议中已经对这些接口做了定义，链接为：http://www.jasig.org/cas/protocol 。下面是我对CAS 各个接口实现的的详细说明。

/login:

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

CAS 默认的登录处理流程

第一次访问Web 应用的流程走向

已经登录web1 后，访问web1 的资源（web1 没有启动session ），或访问web2 的资源

注：

1 ： InitialFlowSetupAction: 是流程的入口。用 request.getContextPath() 的值来设置 cookie 的 Path 值， Cookie 的 path 值是在配置文件里定义的，但这个 Action 负责将 request.getContextPath() 的值设置为 Cookie 的 path 值，这是在 cas 部署环境改变的情况下，灵活地设置 cookie path 的方式；把 cookie 的值以及 service 参数的值放入 requestContext 的 flowscope 里。

2 ： GenerateServiceTicketAction 此 Action 负责根据 service 、 GTC cookie 值生成 ServiceTicket 对象， ServiceTicket 的 ID 就是返回给客户应用的 ticket 参数，如果成功创建 ServiceTicket ，则转发到 WarnAction ，如果创建失败，且 gateway 参数为 true ，则直接 redirect 到客户应用，否则则需要重新认证。

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 的 value 值。

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

WarnAction 就检查用户有没有开启这个功能，如果开启了，则转发到showWarnView, 如果没开启，则直接redirect 到客户应用。

7 ：SendTicketGrantingTicketAction 此Action 负责为response 生成TGC Cookie ，cookie 的值就是 AuthenticationViaFormAction 的 submit 方法生成的 TicketGrantingTicket 对象的 ID 。

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

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

处理逻辑：

1) removeCookie

2) 在服务端删除TicketGrantingTicket 对象（此对象封装了cookie 的value 值）

3 ）redirect 到退出页面，有2 种选择：

if(LogoutController 的followServiceRedirects 属性为true 值，且url 里的service 参数非空){

redirect 到 sevice 参数标识的url

}

else{

redirect 到内置的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 。以ticket 为参数，去缓存里找ServiceTicketImpl 对象，如果能找到，且没有过期，且ServiceTicketImpl 对象对应的service 属性和service 参数对应，则验证通过，验证通过后，请求转发至casServiceSuccessView （cas/WEB-INF/view/jsp/default/protocol/2.0/casServiceValidationSuccess.jsp ），验证不通过，则转发到failureView 。

四认证相关的概念及流程

概念

Credentials 用户提供的用于登录用的凭据信息，如用户名/ 密码、证书、IP 地址、Cookie 值等。比如 U sernamePasswordCredentials ，封装的是用户名和密码。CAS 进行认证的第一步，就是把从UI 或request 对象里取到的用户凭据封装成Credentials 对象，然后交给认证管理器去认证。
AuthenticationHandler 认证Handler, 每种AuthenticationHandler 只能处理一种Credentials ，如 AbstractUsernamePasswordAuthenticationHandler 只负责处理 U sernamePasswordCredentials 。
Principal 封装用户标识，比如 SimplePrincipal, 只是封装了用户名。认证成功后， credentialsToPrincipalResolvers 负责由 Credentials 生成 Principal 对象。
CredentialsToPrincipalResolvers 负责由 Credentials 生成 Principal 对象，每种 CredentialsToPrincipalResolvers 只处理一种Credentials ，比如 UsernamePasswordCredentialsToPrincipalResolver 负责从 U sernamePasswordCredentials 中取出用户名，然后将其赋给生成的 SimplePrincipal 的 ID 属性。
AuthenticationMetaDataPopulators 负责将 Credentials 的一些属性赋值给 Authentication 的 attributes 属性。
Authentication Authentication是认证管理器的最终处理结果， Authentication 封装了 Principal ，认证时间，及其他一些属性（可能来自 Credentials ）。
AuthenticationManager 认证管理器得到 Credentials 对象后，负责调度AuthenticationHandler 去完成认证工作，最后返回的结果是 Authentication 对象。
CentralAuthenticationService CAS 的服务类，对 Web 层提供了一些方法。该类还负责调用 AuthenticationManager 完成认证逻辑。

序列图

CAS 认证处理序列图

类图

CAS 认证类图

iteye_8413

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
【原创】CAS调研总结

本篇文章是对JA-SIG CAS（v3.3）的初步调研总结。一配置实例应用场景： cas 服务部署在192.168.7.115 ，是一个web 应用，访问地址为：https://cas.mycompany.com:8443/cas/ 。web1 应用位于192.168.7.90 ，访问地址为：http://192.168.7.9...
复制链接

扫一扫