手把手教你利用CAS实现单点登录

综合业务系统单点登录（SSO）解决方案

一. SSO (Single Sign-on)原理

SSO 分为Web-SSO和桌面SSO。桌面 SSO 体现在操作系统级别上。Web-SSO体现在客户端，主要特点是： SSO 应用之间使用 Web 协议 ( 如 HTTPS) ，并且只有一个登录入口。我们所讲的SSO，指 Web SSO 。

SSO 的体系中，有下面三种角色：

? User（多个）

? Web应用（多个） ? SSO认证中心（一个）

SSO 实现包含以下三个原则：

? 所有的登录都在 SSO 认证中心进行。

? SSO 认证中心通过一些方法来告诉 Web 应用当前访问用户究竟是不是通过认证的

用户。

? SSO 认证中心和所有的 Web 应用建立一种信任关系。

二. CAS 的基本原理

CAS(Central Authentication Service) 是 Yale 大学发起的构建 Web SSO 的 Java开源项目。

1. CAS术语解释

SSO－Single Sign On，单点登录

TGT－Ticket Granting Ticket，用户身份认证凭证票据

ST－Service Ticket，服务许可凭证票据

TGC－Ticket Granting Cookie，存放用户身份认证凭证票据的cookie

2. CAS 的结构体系

? CAS Server

CAS Server 负责完成对用户信息的认证，需要单独部署，CAS Server 会处理用户名 / 密码等凭证 (Credentials) 。

? CAS Client

CAS Client部署在客户端，当有对本地 Web 应用受保护资源的访问请求，并且需要对请求方进行身份认证，重定向到 CAS Server 进行认证。

3. CAS 协议

基础协议

上图是一个基础的 CAS 协议， CAS Client 以 过滤器的方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个 Web 请求，同时， CAS Client 会分析 HTTP 请求中是否包请求 Service Ticket( 上图中的 Ticket) ，如果没有，则说明该用户是没有经过认证的， CAS Client 会重定向用户请求到 CAS Server （ Step 2 ）。 Step 3 是用户认证过程，如果用户提供了正确的认证信息 ， CAS Server 会产生一个随机的 Service Ticket ，会向 User 发送一个 Ticket granting cookie (TGC) 给 User 的浏览器，并且重定向用户到 CAS Client （附带刚才产生的 Service Ticket），Step 5 和 Step6 是 CAS Client 和 CAS Server 之间完成了一个对用户的身份核实，用 Ticket 查到 Username ，认证通过。

在该协议中，所有与 CAS 的交互均采用 SSL 协议，确保，ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。

4. CAS 如何实现 SSO

当用户访问Helloservice2再次被重定向到 CAS Server 的时候， CAS Server 会主动获到这个 TGC cookie ，然后做下面的事情：

1) 如果 User 的持有 TGC 且其还没失效，那么就走基础协议图的 Step4 ，达到了

SSO 的效果。

2) 如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。

5. CAS服务器接口

uri /login 说明 凭证请求器，参数如下： service：客户端要访问的应用的标识； renew：如果设置这个参数，sso将被绕过；不支持renew和gateway同时存在，若存在则忽略gateway； gateway：如果设置这个参数，CAS将不再问客户端要凭证。 凭证接收器，参数如下： service：客户端要访问的应用的标识；CAS在认证成功后将它的url转发给客户端； warn：在认证转发给其他服务前，客户端必须给予提示。 单点退出，释放cas单点登录的session SSO服务器验证票据的合法性 /logout /proxyValidate 三. 准备工作

1. 准备工具

cas-server-3.5.2.1-release.zip cas-client-3.2.1-release.zip http://downloads.jasig.org/cas/ http://downloads.jasig.org/cas-clients/ 2. 配置环境

CAS 服务器信息 操作系统： WIN7 JDK：jdk1.6.0_38 Tomcat：apache-tomcat-7.0.52 IP地址：192.168.7.106 计算机全名：xxjs-hemindong.zrmx.com CAS客户端信息 Oracle数据库信息 IP地址：192.168.7.106 IP地址：192.168.9.15 用户名：minxinperf 密码：minxinperf123

四. HTTPS验证配置

CAS Server 是一套基于 Java 实现的服务，该服务以一个 Java Web Application 单独部署在与 servlet2.3 兼容的 Web 服务器上，另外，由于 Client 与 CAS Server 之间的交互采用 Https 协议，因此部署 CAS Server 的服务器还需要支持 SSL 协议。

注：证书是单点登录认证系统中很重要的一把钥匙，客户端于服务器的交互安全靠的就是证书；本教程由于是演示所以就自己用JDK自带的keytool工具生成证书；如果以后真正在产品环境中使用肯定要去证书提供机构去申请，证书认证一般都是由VeriSign认证

1. 生成服务端密钥文件

登录服务器打开一个CMD窗口（开始菜单 -> 运行输入cmd后回车）并切换到tomcat安装目录下（如：c:\\tomcat-cas），执行如下命令：

keytool -genkey -alias casserver -keypass demosso -keyalg RSA -keystore casserver.keystore -validity 365

执行后，可以看到tomcat安装目录下生成了一个casserver.keystore文件。如下图：

说明：-alias指定别名为casserver；-keyalg指定RSA算法；-keypass指定私钥密 码；-keystore指定密钥文件名称为casserver.keystore；-validity指定有效期为365天。另外提示的输入 keystore密码应与-keypass指定的相同；您的名字与姓氏是CAS服务器使用的域名（不能是IP，也不能是localhost），其它项随意 填。 注意：服 务器上如果有多个JDK，请确认环境变量中的JDK路径为tomcat所使用的JDK，如果不在环境变量中，也可切换到指定JDK的bin目录下执行命 令；提示的输入keystore密码应与-keypass必须与指定的相同，否则后面tomcat启动会报IO异常（Cannot recover key）。

2. 生成服务端证书

根据以上生成的服务端的密钥文件可以导出服务端证书，执行以下命令：

keytool -export -alias casserver -storepass demosso -file casserver.cer -keystore casserver.keystore

执行后，可以看到tomcat安装目录下生成了一个casserver.cer文件。如下图：

说明：-alias指定别名为casserver；-storepass指定私钥为demosso；-file指定导出证书的文件名为casserver.cer；-keystore指定之前生成的密钥文件的文件名。 注意：-alias和-storepass必须为生成casserver.keystore密钥文件时所指定的别名和密码，否则证书导出失败，报如下错误：

com.minxinloan.common.servlet.SSOLoginFilter

SSOLoginFilter /*

八. 单点登录后进入页面

1. 用户单点登录后进入如下页面：

2. 子系统访问地址配置

通过一张数据库表或是properties文件配置各个子系统的访问地址，在系统启动时通过一个listener加载到系统缓存，方便在选择进入某个子系统时获取到其访问地址，单点登录进入。

3. 直接引用其他子系统地址

在某子系统中可能存在直接调用其他子系统功能模块的情况，只要获取到所调用子系统的访问地址，就可以单点登录透明调用，不受任何影响，也不需要更改子系统代码。

九. 单点退出

在各个子系统退出时需要统一调用

https://xxjs-hemindong.zrmx.com:8443/cas/logout

就能够由CAS服务器统一销毁各个子系统的Session以及服务器、浏览器的票据信息，完成单点退出。

本文来源：https://www.bwwdw.com/article/o8y2.html