这人CAS 在 Tomcat 中实现单点登录1证书生成及导入1.1Server端证书配置1.2JAVA信任证书库D:\Program Files\Java\jdk1.5.0\jre\lib\security\cacertscacerts证书库默认密码-storepass changeit查看证书1.1.1.2 keytool -list -keystore cacerts -storepass changeit如果存在则删除1.1.1.1 keytool -delete -alias tomcatsso -keystore cacerts -storepass changeit创建证书库1.1.1.3 keytool -genkey -keyalg RSA -alias tomcatsso -dname "cn=" -keystore server.keystore -storepass 12345678导出证书1.1.1.4 keytool -export -alias tomcatsso -file tomcatsso.crt -keystore server.keystore -storepass 12345678加入JAVA信任证书库1.1.1.5 keytool -import -alias tomcatsso -file tomcatsso.crt-keystore ../jre/lib/security/cacerts -storepass changeit说明：在生成key的过程，"cn=" 中的为Server端的域名(必填)。
1.2.1TOMCAT 配置SSL支持<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"minSpareThreads="5" maxSpareThreads="75"enableLookups="true" disableUploadTimeout="true"acceptCount="100" maxThreads="200"scheme="https" secure="true"clientAuth="false" sslProtocol="TLS"keystoreFile="D:/javatools/Tomcat 6.0/conf/server.keystore"keystorePass="12345678"truststoreFile="D:/ProgramFiles/Java/jdk1.5.0/jre/lib/security/cacerts"truststorePass="changeit"/>常用的配置属性：clientAuth如果想要Tomcat为了使用这个socket而要求所有SSL客户出示一个客户证书，置该值为true。
keystoreFile如果创建的keystore文件不在Tomcat认为的缺省位置（一个在Tomcat运行的home目录下的叫.keystore的文件），则加上该属性。
可以指定一个绝对路径或依赖$CATALINA_BASE环境变量的相对路径。
keystorePass如果使用了一个与Tomcat预期不同的keystore（和证书）密码，则加入该属性。
keystoreType如果使用了一个PKCS12 keystore，加入该属性。
有效值是JKS和PKCS12。
sslProtocolsocket使用的加密/解密协议。
如果使用的是Sun的JVM，则不建议改变这个值。
据说IBM的1.4.1版的TLS协议的实现和一些流行的浏览器不兼容。
这种情况下，使用SSL。
ciphers此socket允许使用的被逗号分隔的密码列表。
缺省情况下，可以使用任何可用的密码。
algorithm使用的X509算法。
缺省为Sun的实现（SunX509）。
对于IBM JVMS应该使用ibmX509。
对于其它JVM，参考JVM文档取正确的值。
truststoreFile用来验证客户证书的TrustStore文件。
truststorePass访问TrustStore使用的密码。
缺省值是keystorePass。
truststoreType如果使用一个不同于正在使用的KeyStore的TrustStore格式，加入该属性。
有效值是JKS和PKCS12。
单点登录（Single Sign On , 简称 SSO ）是目前比较流行的服务于企业业务整合的解决方案之一， SSO 使得在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
CAS(Central Authentication Service)是一款不错的针对 Web 应用的单点登录框架，本文介绍了 CAS 的原理、协议、在 Tomcat 中的配置和使用，对于采用 CAS 实现轻量级单点登录解决方案的入门读者具有一定指导作用。
CAS 介绍CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。
CAS 具有以下特点：∙开源的企业级单点登录解决方案。
∙CAS Server 为需要独立部署的 Web 应用。
∙CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括 Java, .Net,PHP, Perl, Apache, uPortal, Ruby 等。
CAS 原理和协议从结构上看，CAS 包含两个部分： CAS Server 和 CAS Client。
CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。
图1 是 CAS 最基本的协议过程：图 1. CAS 基础协议CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。
对于访问受保护资源的每个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。
用户在第 3 步中输入认证信息，如果登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5，6 步中与 CAS Server 进行身份合适，以确保 Service Ticket 的合法性。
在该协议中，所有与 CAS 的交互均采用 SSL 协议，确保，ST 和 TGC 的安全性。
协议工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。
另外，CAS 协议中还提供了 Proxy （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考CAS 官方网站上的相关文档。
准备工作本文中的例子以 tomcat5.5 为例进行讲解，下载地址：/download-55.cgi到 CAS 官方网站下载 CAS Server 和 Client，地址分别为：/downloads/cas/cas-server-3.1.1-release.zip/downloads/cas-clients/cas-client-java-2.1.1.zip部署 CAS ServerCAS Server 是一套基于 Java 实现的服务，该服务以一个 Java Web Application 单独部署在与servlet2.3 兼容的 Web 服务器上，另外，由于 Client 与 CAS Server 之间的交互采用 Https 协议，因此部署 CAS Server 的服务器还需要支持 SSL 协议。
当 SSL 配置成功过后，像普通 Web 应用一样将 CAS Server 部署在服务器上就能正常运行了，不过，在真正使用之前，还需要扩展验证用户的接口。
在 Tomcat 上部署一个完整的 CAS Server 主要按照以下几个步骤：配置 Tomcat 使用 Https 协议如果希望 Tomcat 支持 Https，主要的工作是配置 SSL 协议，其配置过程和配置方法可以参考 Tomcat 的相关文档。
不过在生成证书的过程中，会有需要用到主机名的地方，CAS 建议不要使用 IP 地址，而要使用机器名或域名。
部署 CAS ServerCAS Server 是一个 Web 应用包，将前面下载的 cas-server-3.1.1-release.zip 解开，把其中的cas-server-webapp-3.1.1.war 拷贝到 tomcat的 webapps 目录，并更名为 cas.war。
由于前面已配置好tomcat 的 https 协议，可以重新启动 tomcat，然后访问：https://localhost:8443/cas ，如果能出现正常的 CAS 登录页面，则说明 CAS Server 已经部署成功。
虽然 CAS Server 已经部署成功，但这只是一个缺省的实现，在实际使用的时候，还需要根据实际概况做扩展和定制，最主要的是扩展认证 (Authentication) 接口和 CAS Server 的界面。
扩展认证接口CAS Server 负责完成对用户的认证工作，它会处理登录时的用户凭证 (Credentials) 信息，用户名/密码对是最常见的凭证信息。
CAS Server 可能需要到数据库检索一条用户帐号信息，也可能在 XML 文件中检索用户名/密码，还可能通过 LDAP Server 获取等，在这种情况下，CAS 提供了一种灵活但统一的接口和实现分离的方式，实际使用中 CAS 采用哪种方式认证是与 CAS 的基本协议分离开的，用户可以根据认证的接口去定制和扩展。