CAS-Server的配置

一、CAS 介绍（若只是搭建环境，可以忽略）

1.1 基础知识

TGT、ST是CAS1.0协议中就有的票据

TGT（Ticket Grangting Ticket）
关键点：
TGT封装了Cookie值（TGT对象的ID值就是cookie值（指的应当就是TGC吧））以及此Cookie值对应的用户信息。
CAS服务器中存储了 cookie（即TCG）----TGT， 拥有了TGT，用户就可以证明自己在CAS成功登录过。
认证服务认证通过（比如输入了正确的用户和口令后）后就能发放TGT

ST（Service Ticket服务票据）
关键点：
CAS服务器为用户签发的访问某一service的票据；
通过TGT签发一个ST
用户凭借ST去访问service，service拿ST去CAS服务器验证

把两者联系起来：
用户访问service时，service发现用户没有ST，则要求用户去CAS服务器获取ST。用户向CAS服务器发出获取ST的请求，如果用户的请求中包含cookie，则CAS服务器会以此cookie值为key查询缓存中有无TGT，如果存在TGT，则用此TGT签发一个ST，返回给用户。用户凭借ST去访问service，service拿ST去CAS服务器验证，验证通过后，允许用户访问资源。

TGC 安全性
1）对于一个 CAS 用户来说，最重要是要保护它的 TGC ，如果 TGC 不慎被 CAS Server 以外的实体获得， Hacker 能够找到该 TGC ，然后冒充 CAS 用户访问所有授权资源。
2）TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保CAS 的安全性。但 CAS 的传输安全性仅仅依赖于 SSL 。
3）TGC 面临的风险 主要并非传输窃取，而是存活周期内（ logout 前）被使用（如：离开了电脑）或窃取。

ST的安全性：
ST （ Service Ticket ）是通过 Http 传送的，网络中的其他人可以 Sniffer 到其他人的 Ticket 。CAS 协议从几个方面让 Service Ticket 变得更加安全：
1) ST 是基于随机数生成的,且生成的一个ST只能使用一次： CAS协议规定，无论ST验证是否成功， CAS Server都会将服务端的缓存中的该Service Ticket清除 ，从而可以确保一个 Service Ticket 不被使用两次；
2） CAS 规定 Service Ticket 只能存活一定的时间，然后CAS Server会让它失效。可通过在web.xml中配置参数，让ST在多少秒内失效。

1.2 用户访问流程流程实例

用户第一次访问一个CAS 服务的客户web 应用时（例如访问URL ：http://192.168.1.90:8081/web1 ），部署在客户web 应用的cas AuthenticationFilter ，会截获此请求，生成service 参数，然后redirect 到CAS 服务的login 接口，url为https://cas:8443/cas/login?service=http%3A%2F%2F192.168.1.90%3A8081%2Fweb1%2F ，认证成功后，CAS 服务器会生成认证cookie ，写入浏览器，同时将cookie 缓存到服务器本地，CAS 服务器还会根据service 参数生成ticket,ticket 会保存到服务器，也会加在url 后面，然后将请求redirect 回客户web 应用，url 为http://192.168.1.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 的交互。

二、交互认证实战

前置动作：

第一、生成证书

数字证书是指在互联网通讯中标志通讯各方身份信息的一个数字认证，人们可以在网上用它来识别对方的身份

Keytool 是一个Java 数据证书的管理工具 ，Keytool 将密钥和证书存在一个称为keystore的文件中.
在keystore里，包含两种数据：
1、密钥实体——密钥又或者是私钥和配对公钥（采用非对称加密）
2、可信任的证书实体——只包含公钥

keytool -genkey -alias ssodemo -keyalg RSA -keysize 1024 -keypass yinbodotcc -validity 365 -keystore D:\yinbodotcc.keystore -storepass yinbodotcc

keytool -export -alias ssodemo -keystore d:\yinbodotcc.keystore -file d:\ssodemo.crt -storepass yinbodotcc

客户端导入证书（我们这里客户端和服务端都在同一台机器上）：

keytool -import -keystore %JAVA_HOME%\jre\lib\security\cacerts -file d:\ssodemo.crt -alias ssodemo

image.png

image.png

image.png

第二、配置本地DNS

image.png

这里server.yinbodotcc. com和keygen命令中“名字与姓氏”后面输入的要一样才行

第三、CAS-Server环境部署

1、 部署CAS-Server相关的Tomcat
解压apache-tomcat-7.0.100-windows-x64.zip，修改apache-tomcat-7.0.100\conf\server.xml文件

image.png

image.png

2、部署CAS-Server
http://www.jasig.org/cas/download 下载 cas-server-4.0.0-release.zip，
取cas-server-4.0.0-release\cas-server-4.0.0\modules\cas-server-webapp-4.0.0.war 放到 apache-tomcat-7.0.100\webapps\下, 然后启动浏览器（war会被自动被解压并动态加载）：

image.png

2.1 使用MySQL存储用户认证口令

1、需要的几个jar包：

把c3p0-0.9.1.2.jar、cas-server-support-jdbc-4.0.0.jar和mysql-connector-java-5.1.13-bin.jar放到E:\apache-tomcat-7.0.57\webapps\cas\WEB-INF\lib目录下：

image.png

2、修改配置，支持mysql数据库交互验证

配置文件：deployerConfigContext.xml

image.png

image.png

、

为便于copy，配置文件关键部分摘录如下：

image.png

登录演示效果如下：

image.png

image.png

2.2 使用LDAP（openLDAP）里面存储的用户和口令

2.3 使用Redis里面存储的用户和口令