cas协议，以及tomcat搭建cas服务器

时间  2019-11-29
标签 cas 协议 以及 tomcat 搭建 服务器 栏目 Tomcat 繁體版
原文   原文链接

1.      CAS 简介

1.1.  What is CAS ？

CAS （ Central Authentication Service ） 是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登陆解决方法（属于 Web SSO ）。html

CAS 开始于 2001 年， 并在 2004 年 12 月正式成为 JA-SIG 的一个项目。前端

1.2.  主要特性

一、   开源的、多协议的 SSO 解决方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。java

二、   支持多种认证机制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates等；mysql

三、   安全策略：使用票据（ Ticket ）来实现支持的认证协议；linux

四、   支持受权：能够决定哪些服务能够请求和验证服务票据（ Service Ticket ）；程序员

五、   提供高可用性：经过把认证过的状态数据存储在 TicketRegistry 组件中，这些组件有不少支持分布式环境的实现，如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等；web

六、   支持多种客户端： Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。算法

 

2.      SSO 单点登陆原理

本文内容主要针对 Web SSO 。spring

2.1.  什么是SSO

单点登陆（ Single Sign-On , 简称 SSO ）是目前比较流行的服务于企业业务整合的解决方案之一， SSO 使得在多个应用系统中，用户只须要 登陆一次 就能够访问全部相互信任的应用系统。sql

2.2.  SSO 原理

2.2.1.      SSO 体系中的角色

通常 SSO 体系主要角色有三种：

一、 User （多个）

二、 Web 应用（多个）

三、 SSO 认证中心（ 1 个 ）

2.2.2.      SSO 实现模式的原则

SSO 实现模式通常包括如下三个原则：

一、   全部的认证登陆都在 SSO 认证中心进行；

二、   SSO 认证中心经过一些方法来告诉 Web 应用当前访问用户到底是不是已经过认证的用户；

三、   SSO 认证中心和全部的 Web 应用创建一种信任关系，也就是说 web 应用必须信任认证中心。（单点信任）

2.2.3.      SSO 主要实现方式

SSO 的主要实现方式有：

一、   共享 cookies

基于共享同域的 cookie 是 Web 刚开始阶段时使用的一种方式，它利用浏览同域名之间自动传递 cookies 机制，实现两个域名之间系统令牌传递问题；另外，关于跨域问题，虽然 cookies 自己不跨域，但能够利用它实现跨域的 SSO 。如：代理、暴露 SSO 令牌值等。

缺点：不灵活并且有很多安全隐患，已经被抛弃。

二、   Broker-based( 基于经纪人 )

这种技术的特色就是，有一个集中的认证和用户账号管理的服务器。经纪人给被用于进一步请求的电子身份存取。中央数据库的使用减小了管理的代价，并为认证提供一个公共和独立的 "第三方 " 。例如 Kerberos 、 Sesame 、 IBM KryptoKnight （凭证库思想 ) 等。 Kerberos是由麻省理工大学发明的安全认证服务，已经被 UNIX 和 Windows 做为默认的安全认证服务集成进操做系统。

三、   Agent-based （基于代理人）

在这种解决方案中，有一个自动地为不一样的应用程序认证用户身份的代理程序。这个代理程序须要设计有不一样的功能。好比，它可使用口令表或加密密钥来自动地将认证的负担从用户移开。代理人被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个 " 翻译 " 。例如 SSH 等。

四、   Token-based

例如 SecureID,WebID ，如今被普遍使用的口令认证，好比 FTP 、邮件服务器的登陆认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用。

五、   基于网关

六、   基于 SAML

SAML(Security Assertion Markup Language ，安全断言标记语言）的出现大大简化了 SSO ，并被 OASIS 批准为 SSO 的执行标准 。开源组织 OpenSAML 实现了 SAML 规范。

 

3.      CAS 的基本原理

3.1.  结构体系

从结构体系看， CAS 包括两部分： CAS Server 和 CAS Client 。

3.1.1.      CAS Server

CAS Server 负责完成对用户的认证工做 , 须要独立部署 , CAS Server 会处理用户名 / 密码等凭证(Credentials) 。

3.1.2.      CAS Client

负责处理对客户端受保护资源的访问请求，须要对请求方进行身份认证时，重定向到 CAS Server 进行认证。（原则上，客户端应用再也不接受任何的用户名密码等 Credentials ）。

CAS Client 与受保护的客户端应用部署在一块儿，以 Filter 方式保护受保护的资源。

3.2.  CAS 原理和协议

3.2.1.      基础模式

基础模式 SSO 访问流程主要有如下步骤：

1. 访问服务： SSO 客户端发送请求访问应用系统提供的服务资源。

2. 定向认证： SSO 客户端会重定向用户请求到 SSO 服务器。

3. 用户认证：用户身份认证。

4. 发放票据： SSO 服务器会产生一个随机的 Service Ticket 。

5. 验证票据： SSO 服务器验证票据 Service Ticket 的合法性，验证经过后，容许客户端访问服务。

6. 传输用户信息： SSO 服务器验证票据经过后，传输用户认证结果信息给客户端。

下面是 CAS 最基本的协议过程：

 

 

基础协议图

 

如上图： CAS Client 与受保护的客户端应用部署在一块儿，以 Filter 方式保护 Web 应用的受保护资源，过滤从客户端过来的每个 Web 请求，同时， CAS Client 会分析 HTTP 请求中是否包含请求 Service Ticket( ST 上图中的 Ticket) ，若是没有，则说明该用户是没有通过认证的；因而 CAS Client 会重定向用户请求到 CAS Server （ Step 2 ），并传递 Service （要访问的目的资源地址）。 Step 3 是用户认证过程，若是用户提供了正确的 Credentials ， CAS Server 随机产生一个至关长度、惟1、不可伪造的 Service Ticket ，并缓存以待未来验证，而且重定向用户到 Service 所在地址（附带刚才产生的 Service Ticket ） , 并为客户端浏览器设置一个 Ticket Granted Cookie （ TGC ） ； CAS Client在拿到 Service 和新产生的 Ticket 事后，在 Step 5 和 Step6 中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。

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

    CAS 请求认证时序图以下：

 

  

3.2.1.      CAS 如何实现 SSO

当用户访问另外一个应用的服务再次被重定向到 CAS Server 的时候， CAS Server 会主动获到这个 TGC cookie ，而后作下面的事情：

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

2) 若是 TGC 失效，那么用户仍是要从新认证 ( 走基础协议图的 Step3) 。

 

3.2.2.      CAS 代理模式

该模式形式为用户访问 App1 ， App1 又依赖于 App2 来获取一些信息，如： User -->App1 -->App2 。

这种状况下，假设 App2 也是须要对 User 进行身份验证才能访问，那么，为了避免影响用户体验（过多的重定向致使 User 的 IE 窗口不停地闪动 ) ， CAS 引入了一种 Proxy 认证机制，即 CAS Client 能够代理用户去访问其它 Web 应用。

代理的前提是须要 CAS Client 拥有用户的身份信息 ( 相似凭据 ) 。以前咱们提到的 TGC 是用户持有对本身身份信息的一种凭据，这里的 PGT 就是 CAS Client 端持有的对用户身份信息的一种凭据。凭借TGC ， User 能够免去输入密码以获取访问其它服务的 Service Ticket ，因此，这里凭借 PGT ， Web应用能够代理用户去实现后端的认证，而 无需前端用户的参与 。

下面为代理应用（ helloService ）获取 PGT 的过程： （注： PGTURL 用于表示一个 Proxy 服务，是一个回调连接； PGT 至关于代理证； PGTIOU 为取代理证的钥匙，用来与 PGT 作关联关系；）

 

  

如上面的 CAS Proxy 图所示， CAS Client 在基础协议之上，在验证 ST 时提供了一个额外的PGT URL( 并且是 SSL 的入口 ) 给 CAS Server ，使得 CAS Server 能够经过 PGT URL 提供一个 PGT 给 CAS Client 。

CAS Client 拿到了 PGT(PGTIOU-85 … ..ti2td) ，就能够经过 PGT 向后端 Web 应用进行认证。

下面是代理认证和提供服务的过程：

 

 

如上图所示， Proxy 认证与普通的认证其实差异不大， Step1 ， 2 与基础模式的 Step1,2 几乎同样，惟一不一样的是， Proxy 模式用的是 PGT 而不是 TGC ，是 Proxy Ticket （ PT ）而不是Service Ticket 。

 

3.2.3.      辅助说明

CAS 的 SSO 实现方式可简化理解为： 1 个 Cookie 和 N 个 Session 。 CAS Server 建立 cookie，在全部应用认证时使用，各应用经过建立各自的 Session 来标识用户是否已登陆。

用户在一个应用验证经过后，之后用户在同一浏览器里访问此应用时，客户端应用中的过滤器会在 session 里读取到用户信息，因此就不会去 CAS Server 认证。若是在此浏览器里访问别的 web 应用时，客户端应用中的过滤器在 session 里读取不到用户信息，就会去 CAS Server 的 login 接口认证，但这时CAS Server 会读取到浏览器传来的 cookie （ TGC ），因此 CAS Server 不会要求用户去登陆页面登陆，只是会根据 service 参数生成一个 Ticket ，而后再和 web 应用作一个验证 ticket 的交互而已。

3.3.  术语解释

CAS 系统中设计了 5 中票据： TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。

  • Ticket-granting cookie(TGC) ：存放用户身份认证凭证的 cookie ，在浏览器和 CAS Server间通信时使用，而且只能基于安全通道传输（ Https ），是 CAS Server 用来明确用户身份的凭证；
  • Service ticket(ST) ：服务票据，服务的唯一标识码 , 由 CAS Server 发出（ Http 传送），经过客户端浏览器到达业务服务器端；一个特定的服务只能有一个唯一的 ST ；
  • Proxy-Granting ticket （ PGT ）：由 CAS Server 颁发给拥有 ST 凭证的服务， PGT 绑定一个用户的特定服务，使其拥有向 CAS Server 申请，得到 PT 的能力；
  • Proxy-Granting Ticket I Owe You （ PGTIOU ） : 做用是将经过凭证校验时的应答信息由 CAS Server 返回给 CAS Client ，同时，与该 PGTIOU 对应的 PGT 将经过回调连接传给 Web应用。 Web 应用负责维护 PGTIOU 与 PGT 之间映射关系的内容表；
  • Proxy Ticket (PT) ：是应用程序代理用户身份对目标程序进行访问的凭证；

 

其它说明以下：

  • Ticket Granting ticket(TGT) ：票据受权票据，由 KDC 的 AS 发放。即获取这样一张票据后，之后申请各类其余服务票据 (ST) 便没必要再向 KDC 提交身份认证信息 (Credentials) ；
  • Authentication service(AS) --------- 认证用服务，索取 Credentials ，发放 TGT ；
  • Ticket-granting service (TGS) --------- 票据受权服务，索取 TGT ，发放 ST ；
  • KDC( Key Distribution Center ) ---------- 密钥发放中心；

 

4.      CAS 安全性

CAS 的安全性仅仅依赖于 SSL 。使用的是 secure cookie 。

4.1.  TGC/PGT 安全性

对于一个 CAS 用户来讲，最重要是要保护它的 TGC ，若是 TGC 不慎被 CAS Server 之外的实体得到， Hacker 可以找到该 TGC ，而后冒充 CAS 用户访问 全部 受权资源。 PGT 的角色跟 TGC 是同样的。

从基础模式能够看出， TGC 是 CAS Server 经过 SSL 方式发送给终端用户，所以，要截取 TGC 难度很是大，从而确保 CAS 的安全性。

TGT 的存活周期默认为 120 分钟。

4.2.  ST/PT 安全性

ST （ Service Ticket ）是经过 Http 传送的，所以网络中的其余人能够 Sniffer 到其余人的 Ticket。 CAS 经过如下几方面来使 ST 变得更加安全（事实上都是能够配置的）：

一、   ST 只能使用一次

CAS 协议规定，不管 Service Ticket 验证是否成功， CAS Server 都会清除服务端缓存中的该 Ticket ，从而能够确保一个 Service Ticket 不被使用两次。

二、   ST 在一段时间内失效

CAS 规定 ST 只能存活必定的时间，而后 CAS Server 会让它失效。默认有效时间为 5 分钟。

三、   ST 是基于随机数生成的

ST 必须足够随机，若是 ST 生成规则被猜出， Hacker 就等于绕过 CAS 认证，直接访问 对应的服务。

 

5.      参考资料

一、 https://wiki.jasig.org/display/CASUM/Introduction

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

三、 http://www.ibm.com/developerworks/cn/opensource/os-cn-cas/index.html

四、 http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html

五、 http://baike.baidu.com/view/190743.htm

 

 

 CAS单点登陆(SSO)完整教程(2012-02-01更新)

1、教程说明

前言

  • 教程目的：从头至尾细细道来单点登陆服务器及客户端应用的每一个步骤
  • 单点登陆（SSO）：请看百科解释猛击这里打开
  • 本教程使用的SSO服务器是Yelu大学研发的CAS(Central Authentication Server)，
    官网：http://www.jasig.org/cas

本教程环境：

  • Tomcat6.0.29
  • JDK6
  • CAS Server版本：cas-server-3.4.3.一、cas-server-3.4.10
  • CAS Client版本：cas-client-3.1.十二、cas-client-3.2.1
  • 教程撰写日期：2010-11-05(初版)、2011-11-05(一年后更新)、2012-02-01(异常处理)
  • 教程做者：咖啡兔

2、建立证书

啰嗦几句：证书是单点登陆认证系统中很重要的一把钥匙，客户端于服务器的交互安全靠的就是证书；本教程因为是演示因此就本身用JDK自带的keytool工具生成证书；若是之后真正在产品环境中使用确定要去证书提供商去购买，证书认证通常都是由VeriSign认证，中文官方网站：http://www.verisign.com/cn/

用JDK自带的keytool工具生成证书：

keytool -genkey -alias wsria -keyalg RSA -keystore d:/keys/wsriakey

 

无图不给力，有图有真相：

用keytool生成证书

具体的输入项图片中都有说明，有一点我要解释一下；在输入完密码后提示输入域名是我输入的是sso.wsria.com，其实这个域名是不存在的，可是我为了演示因此虚拟了这个域名，技巧在于修改

C:\Windows\System32\drivers\etc\hosts

添加内容以下：

127.0.0.1  sso.wsria.com

这样在访问sso.wsria.com的时候实际上是访问的127.0.0.1也就是本机

严重提醒：提示输入域名的时候不能输入IP地址

3、导出证书

D:\keys>keytool -export -file d:/keys/wsria.crt -alias wsria -keystore d:/keys/wsriakey

特别提示：若是提示：

keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect

那么请输入密码：changeit

来点颜色：

用keytool导出证书

至此导出证书完成，能够分发给应用的JDK使用了，接下来说解客户端的JVM怎么导入证书。

4、为客户端的JVM导入证书

keytool -import -keystore D:\tools\jdk\1.6\jdk1.6.0_20\jre\lib\security\cacerts -file D:/keys/wsria.crt -alias wsria

来点颜色瞧瞧：

用keytool导出证书

特别说明

D:\tools\jdk\1.6\jdk1.6.0_20\jre\lib\security -- 是jre的目录；密码仍是刚刚输入的密码。至此证书的建立、导出、导入到客户端JVM都已完成，下面开始使用证书到Web服务器中，本教程使用tomcat。

5、应用证书到Web服务器-Tomcat

说是应用起始作的事情就是启用Web服务器(Tomcat)的SSL，也就是HTTPS加密协议，为何加密我就不用啰嗦了吧……准备好一个干净的tomcat，本教程使用的apache-tomcat-6.0.29打开tomcat目录的conf/server.xml文件，开启83和87行的注释代码，并设置keystoreFile、keystorePass修改结果以下：

?
1
2
<  connector  port  =  "8443"  protocol  =  "HTTP/1.1"  sslenabled  =  "true"  maxthreads  =  "150"  scheme  =  "https"  secure  =  "true"  clientauth  =  "false"  sslprotocol  =  "TLS"  keystorefile  =  "D:/keys/wsriakey"  keystorepass  =  "wsria.com"  >
connector  >

参数说明：

  • keystoreFile：在第一步建立的key存放位置
  • keystorePass：建立证书时的密码

好了，到此Tomcat的SSL启用完成，如今你能够启动tomcat试一下了，例如本教程输入地址：https://sso.wsria.com:8443/打开的是：

浏览器提示证书错误

好的，那么咱们点击“继续浏览此网站(不推荐)。如今进入Tomcat目录了吧，若是是那么你又向成功迈进了一步。

OK，接下来要配置CAS服务器了。

6、CAS服务器初体验

  • CAS服务端下载：http://www.jasig.org/cas/download

  • 下载完成后将cas-server-3.4.3.1.zip解压，解压cas-server-3.4.3/modules/cas-server-webapp-3.4.3.1.war，更名为cas，而后复制cas目录到你的tomcat/webapp目录下

  • 如今能够访问CAS应用了，固然要使用HTTPS加密协议访问，例如本教程地址：https://sso.wsria.com:8443/cas/login ，如今打开了CAS服务器的页面输入admin/admin点击登陆（CAS默认的验证规则只要用户名和密码相同就经过）因此若是你看到下面的这张图片你就成功了

CAS登陆成

你成功了吗？若是没有成功请再检查以上步骤！

2011-11-05更新说明

使用Maven构建：

使用cmd或者shell进入cas-server-3.4.10目录，运行：

?
1
mvn package -pl cas-server-webapp,cas-server-support-jdbc

意思是只须要构建cas-server-webapp和cas-server-support-jdbc，若是须要其余的请根据文件夹名称设置或者构建所有模块，打包所有模块命令：mvn package 便可。打包过程当中会从网络下载须要的jar包，请耐心等待；若是在~/.m2/settings.xml中定义了mirror代理 ，那么请把随便修改一个字符，不然下载jar包会失败！

打包完成后就能够从cas-server-webapp/target/cas.war复制到你的tomcat/webapp中；或者直接复制cas-server-webapp/target/cas-server-webapp-3.4.10目录到tomcat/webapp目录下，其余步骤和上面同样。

7、CAS服务器深刻配置

上面的初体验仅仅是简单的身份验证，实际应用中确定是要读取数据库的数据，下面咱们来进一步配置CAS服务器怎么读取数据库的信息进行身份验证。首先打开

tomcat/webapp/cas/WEB-INF/deployerConfigContext.xml
配置的地方以下：

 

找到第92行处，注释掉：SimpleTestUsernamePasswordAuthenticationHandler这个验证Handler，这个是比较简单的，只是判断用户名和密码相同便可经过，这个确定不能在实际应用中使用，弃用！

注释掉92行后在下面添加下面的代码：

?
1
2
3
4
5
<  bean  class  =  "org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler" >
<  property  name  =  "dataSource"  ref  =  "dataSource"  >  property  >
<  property  name  =  "sql"  value  =  "select password from t_admin_user where login_name=?"  >  property  >
<  property  name  =  "passwordEncoder"  ref  =  "MD5PasswordEncoder"  >  property  >
bean  >

在文件的末尾以前加入以下代码：

?
1
2
3
4
5
6
7
8
9
10
11
12
<  bean  id  =  "dataSource"  class  =  "org.springframework.jdbc.datasource.DriverManagerDataSource"  >
<  property  name  =  "driverClassName"  ><  value  >com.mysql.jdbc.Driver  value  >  property  >
<  property  name  =  "url"  ><  value  >jdbc:mysql:///wsriademo  value  >  property  >
<  property  name  =  "username"  ><  value  >root  value  >  property  >
<  property  name  =  "password"  ><  value  >root  value  >  property  >
bean  >
 
<  bean  id  =  "MD5PasswordEncoder"  class  =  "org.jasig.cas.authentication.handler.DefaultPasswordEncoder"  >
<  constructor-arg  index  =  "0"  >
<  value  >MD5  value  >
constructor-arg  >
bean  >

复制cas-server-3.4.3.1\modules\cas-server-support-jdbc-3.4.3.1.jar和mysql驱动jar包到tomcat/webapp/cas/WEB-INF/lib目录

配置解释：

  • QueryDatabaseAuthenticationHandler，是cas-server-support-jdbc提供的查询接口其中一个，QueryDatabaseAuthenticationHandler是经过配置一个 SQL 语句查出密码，与所给密码匹配

  • dataSource,我就不用解释了吧，就是使用JDBC查询时的数据源

  • sql，语句就是查询哪一张表，本例根据t_admin_user表的login_name字段查询密码，CAS会匹配用户输入的密码，若是匹配则经过；下面是t_admin_user的表结构：

?
1
2
3
4
5
6
7
8
create  table  t_admin_user (
id  bigint  not  null  auto_increment,
email  varchar  (255),
login_name  varchar  (255)  not  null  unique  ,
name  varchar  (255),
password  varchar  (255),
primary  key  (id)
) ENGINE=InnoDB;
  • passwordEncoder，这个就算是本身加的盐巴了，意思很明显就是处理密码的加密，看你的应用中数据库保存的是明码仍是加密过的，好比本例是使用MD5加密的，因此配置了MD5PasswordEncoder这个Handler，cas内置了MD5的功能因此只须要配置一下就能够了；若是在实际应用中使用的是公司本身的加密算法那么就须要本身写一个Handler来处理密码，实现方式也比较简单，建立一个类继承org.jasig.cas.authentication.handler.PasswordEncoder而后在encode方法中加密用户输入的密码而后返回便可

8、配置CAS客户端

添加cas-client的jar包，有两种方式：

传统型

下载cas-client，地址：http://www.ja-sig.org/downloads/cas-clients/，而后解压cas-client-3.1.12.zip，在modules文件夹中有须要的jar包，请根据本身的项目状况选择使用

2011-11-05更新：

用maven打包server的方式同样，在cas-client-3.2.1目录中运行命令：

?
1
mvn package -pl cas-client-core -DskipTests=  true

而后从target目录中复制cas-client-core-3.2.1.jar到应用的WEB-INF/lib目录中

Maven型

?
1
2
3
4
5
<  dependency  >
<  groupid  >org.jasig.cas.client  groupid  >
<  artifactid  >cas-client-core  artifactid  >
<  version  >3.1.12  version  >
dependency  >

设置filter

编辑web.xml，而后粘贴下面的代码：

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
 
<  listener  >
<  listener-class  >org.jasig.cas.client.session.SingleSignOutHttpSessionListener  listener-class  >
listener  >
 
 
<  filter  >
<  filter-name  >CAS Single Sign Out Filter  filter-name  >
<  filter-class  >org.jasig.cas.client.session.SingleSignOutFilter  filter-class  >
filter  >
<  filter-mapping  >
<  filter-name  >CAS Single Sign Out Filter  filter-name  >
<  url-pattern  >/*  url-pattern  >
filter-mapping  >
 
 
<  filter  >
<  filter-name  >CASFilter  filter-name  >
<  filter-class  >org.jasig.cas.client.authentication.AuthenticationFilter  filter-class  >
<  init-param  >
<  param-name  >casServerLoginUrl  param-name  >
<  param-value  >https://sso.wsria.com:8443/cas/login  param-value  >
init-param  >
<  init-param  >
 
<  param-name  >serverName  param-name  >
<  param-value  >http://localhost:10000  param-value  >
init-param  >
filter  >
<  filter-mapping  >
<  filter-name  >CASFilter  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  >https://sso.wsria.com:8443/cas  param-value  >
init-param  >
<  init-param  >
<  param-name  >serverName  param-name  >
<  param-value  >http://localhost:10000  param-value  >
init-param  >
filter  >
<  filter-mapping  >
<  filter-name  >CAS Validation Filter  filter-name  >
<  url-pattern  >/*  url-pattern  >
filter-mapping  >
 
 
<  filter  >
<  filter-name  >CAS HttpServletRequest Wrapper Filter  filter-name  >
<  filter-class  >
org.jasig.cas.client.util.HttpServletRequestWrapperFilter  filter-class  >
filter  >
<  filter-mapping  >
<  filter-name  >CAS HttpServletRequest Wrapper Filter  filter-name  >
<  url-pattern  >/*  url-pattern  >
filter-mapping  >
 
 
<  filter  >
<  filter-name  >CAS Assertion Thread Local Filter  filter-name  >
<  filter-class  >org.jasig.cas.client.util.AssertionThreadLocalFilter  filter-class  >
filter  >
<  filter-mapping  >
<  filter-name  >CAS Assertion Thread Local Filter  filter-name  >
<  url-pattern  >/*  url-pattern  >
filter-mapping  >
 
 
<  filter  >
<  display-name  >AutoSetUserAdapterFilter  display-name  >
<  filter-name  >AutoSetUserAdapterFilter  filter-name  >
<  filter-class  >com.wsria.demo.filter.AutoSetUserAdapterFilter  filter-class  >
filter  >
<  filter-mapping  >
<  filter-name  >AutoSetUserAdapterFilter  filter-name  >
<  url-pattern  >/*  url-pattern  >
filter-mapping  >
 

每一个Filter的功能我就很少说了，都有注释的，关键要解释一下AutoSetUserAdapterFilter的做用和原理.查看完整的web.xml请 猛击这里

利用AutoSetUserAdapterFilter自动根据CAS信息设置Session的用户信息

先看一下这个AutoSetUserAdapterFilter.java的源码

好的，若是你是老程序员应该很快就清楚Filter的目的，若是不太懂我再讲解一下；主要是经过CAS的const_cas_assertion获取从CAS服务器登录的用户名，而后再根据系统内部的用户工具（UserUtil.java）来判断是否已经登陆过，若是没有登陆根据登陆名从数据库查询用户信息，最后使用设置把用户信息设置到当前session中。这样就把用户信息保存到了Sessino中，咱们就能够经过UserUtil工具来获取当前登陆的用户了，我在实例项目中也加入了此功能演示，请看代码：main.jsp的第44行处

补充一下：

若是是为一个老项目添加单点登陆功能，那么基本不须要其余的修改，设置好上面的filter便可；固然最好获取用户信息的地方都调用一个工具类，统一管理不容易出错。

9、单点退出

这个比较简单，把你的退出连接设置为：https://sso.wsria.com/cas/logout 便可。

10、美化CAS服务器界面

CAS服务端(cas-server)的界面只能在测试的时候用一下，真正系统上线确定须要定制开发本身的页面，就像网易和CSDN的统一认证平台同样，全部子系统的认证都经过此平台来转接，你们能够根据他们的页面本身定制出适合所属应用或者公司的界面；简单介绍一下吧，复制cas\WEB-INF\view\jsp\default\ui的一些JSP文件，每个文件的用途文件名已经区分了，本身修改了替换一下就能够了。例如：

  • 登陆界面：casLoginView.jsp
  • 登陆成功：casGenericSuccess.jsp
  • 登出界面：casLogoutView.jsp

11、结束语

花了一下午时间终于写完了，总共十项也算完美了。如今看来起始利用CAS实现单点登陆其实不难，不要畏惧，更不要排斥！本教程后面的代码部分均来自http://code.google.com/p/wsria的项目分支wsria-demo-sso

和本教程相关资料下载

  • 本教程使用的演示程序，点击这里
  • 使用keytool生成的key和证书，点击这里

到此本教程所有结束，但愿看完后对你有帮助，若是有帮助还望继续推荐给其余人，有说明意见或者问题请回复或者IM联系我。

12、疑难问题

若是遇到了意料以外的问题请参考文章的评论部分，或许能找到问题的缘由以及解决办法！

javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching casserver found

因为建立证书的域名和在应用中配置的cas服务域名不一致致使如下错误，详细请参考：

十3、更新记录_2011-11-05

整整一年以后由于须要为客户搭建CAS换季再次更新本文章，不知道碰巧呢碰巧呢仍是碰巧呢，反正就是11.5号了……在这里还要感谢你们对个人支持，要否则这篇教程也不会一直处于本博客的第一位……

不知道从哪一个版本开始cas全面使用了maven构建项目，因此须要安装apache maven工具来构建源码，下面step by step讲解如何构建（面向没有接触过maven的童鞋）

  • 下载Maven：打开http://maven.apache.org/download.html后下载对应的包，windows用户请下载Binary zip格式的压缩包，linux或者unix用户请下载Binary tar.gz**格式的压缩包

  • 安装、配置Maven：解压压缩包到一个目录，例如/home/kafeitu/tools/apache/apache-maven-3.0.3，而后设置系统环境变量M3_HOME=/home/kafeitu/tools/apache/apache-maven-3.0.3，在PAT变量中添加路径

    • windows用户：;%M3_HOME%/bin
    • Linux用户：在.bashrc或者/et/profile文件中找到PATH，添加:$M3_HOME/bin

  • 验证安装：从新打开一个命令窗口，

    • linux用户能够运行：
      ?
      1
      source  .bashrc
      或者
      ?
      1
      source  /etc/profile
    • windows用户从新打开cmd窗口

在cmd或者shell中进入解压的cas server目录后运行:mvn -version后若是看到打印系统信息和maven版本信息后证实配置ok

十4、更新记录_2011-11-18

你也能够申请免费的StartSSL CA证书:StartSSL(公司名：StartCom)也是一家CA机构，它的根证书好久以前就被一些具备开源背景的浏览器支持(Firefox浏览器、谷歌Chrome浏览器、苹果Safari浏览器等)。申请地址：http://www.startssl.com申请方法参考：http://www.linuxidc.com/Linux/2011-11/47478.htm

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程