minSpareThreads="5"maxSpareThreads="75"
enableLookups="true"disableUploadTimeout="true"
acceptCount="100"maxThreads="200"
scheme="https"secure="true"
clientAuth="false"sslProtocol="TLS"
keystoreFile="D:
/javatools/Tomcat6.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
如果使用了一个PKCS12keystore，加入该属性。
有效值是JKS和PKCS12。
sslProtocol
socket使用的加密/解密协议。
如果使用的是Sun的JVM，则不建议改变这个值。
据说IBM的1.4.1版的TLS协议的实现和一些流行的浏览器不兼容。
这种情况下，使用SSL。
ciphers
此socket允许使用的被逗号分隔的密码列表。
缺省情况下，可以使用任何可用的密码。
algorithm
使用的X509算法。
缺省为Sun的实现（SunX509）。
对于IBMJVMS应该使用ibmX509。
对于其它JVM，参考JVM文档取正确的值。
truststoreFile
用来验证客户证书的TrustStore文件。
truststorePass
访问TrustStore使用的密码。
缺省值是keystorePass。
truststoreType
如果使用一个不同于正在使用的KeyStore的TrustStore格式，加入该属性。
有效值是JKS和PKCS12。
启动Tomcat，测试:
443
单点登录（SingleSignOn,简称SSO）是目前比较流行的服务于企业业务整合的解决方案之一，SSO使得在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
CAS（CentralAuthenticationService）是一款不错的针对Web应用的单点登录框架，本文介绍了CAS的原理、协议、在Tomcat中的配置和使用，对于采用CAS实现轻量级单点登录解决方案的入门读者具有一定指导作用。
CAS介绍
CAS是Yale大学发起的一个开源项目，旨在为Web应用系统提供一种可靠的单点登录方法，CAS在2004年12月正式成为JA-SIG的一个项目。
CAS具有以下特点：
∙开源的企业级单点登录解决方案。
准备工作
本文中的例子以tomcat5.5为例进行讲解，下载地址：
http:
//tomcat.apache.org/download-55.cgi
到CAS官方网站下载CASServer和Client，地址分别为：
http:
//www.ja-sig.org/downloads/cas/cas-server-3.1.1-release.zip
http:
//www.ja-sig.org/downloads/cas-clients/cas-client-java-2.1.1.zip
部署CASServer
CASServer是一套基于Java实现的服务，该服务以一个JavaWebApplication单独部署在与servlet2.3兼容的Web服务器上，另外，由于Client与CASServer之间的交互采用Https协议，因此部署CASServer的服务器还需要支持SSL协议。
当SSL配置成功过后，像普通Web应用一样将CASServer部署在服务器上就能正常运行了，不过，在真正使用之前，还需要扩展验证用户的接口。
在Tomcat上部署一个完整的CASServer主要按照以下几个步骤：
配置Tomcat使用Https协议
如果希望Tomcat支持Https，主要的工作是配置SSL协议，其配置过程和配置方法可以参考Tomcat的相关文档。
不过在生成证书的过程中，会有需要用到主机名的地方，CAS建议不要使用IP地址，而要使用机器名或域名。
部署CASServer
CASServer是一个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登录页面，则说明CASServer已经部署成功。
虽然CASServer已经部署成功，但这只是一个缺省的实现，在实际使用的时候，还需要根据实际概况做扩展和定制，最主要的是扩展认证（Authentication）接口和CASServer的界面。
扩展认证接口
CASServer负责完成对用户的认证工作，它会处理登录时的用户凭证（Credentials）信息，用户名/密码对是最常见的凭证信息。
CASServer可能需要到数据库检索一条用户帐号信息，也可能在XML文件中检索用户名/密码，还可能通过LDAPServer获取等，在这种情况下，CAS提供了一种灵活但统一的接口和实现分离的方式，实际使用中CAS采用哪种方式认证是与CAS的基本协议分离开的，用户可以根据认证的接口去定制和扩展。
扩展AuthenticationHandler
CAS提供扩展认证的核心是AuthenticationHandler接口，该接口定义如清单1下：
清单1.AuthenticationHandler定义
publicinterfaceAuthenticationHandler{
/**
*Methodtodetermineifthecredentialssuppliedarevalid.
*@paramcredentialsThecredentialstovalidate.
*@returntrueifvalid,returnfalseotherwise.
*@throwsAuthenticationExceptionAnAuthenticationExceptioncancontain
*detailsaboutwhyaparticularauthenticationrequestfailed.
*/
booleanauthenticate（Credentialscredentials）throwsAuthenticationException;
/**
*Methodtocheckifthehandlerknowshowtohandlethecredentials
*provided.ItmaybeasimplecheckoftheCredentialsclassorsomething
*morecomplicatedsuchasscanningtheinformationcontainedinthe
*Credentialsobject.
*@paramcredentialsThecredentialstocheck.
*@returntrueifthehandlersupportstheCredentials,falseothewrise.
*/
booleansupports（Credentialscredentials）;
}
该接口定义了2个需要实现的方法，supports（）方法用于检查所给的包含认证信息的Credentials是否受当前AuthenticationHandler支持；而authenticate（）方法则担当验证认证信息的任务，这也是需要扩展的主要方法，根据情况与存储合法认证信息的介质进行交互，返回boolean类型的值，true表示验证通过，false表示验证失败。
CAS3中还提供了对AuthenticationHandler接口的一些抽象实现，比如，可能需要在执行authenticate（）方法前后执行某些其他操作，那么可以让自己的认证类扩展自清单2中的抽象类：
清单2.AbstractPreAndPostProcessingAuthenticationHandler定义
publicabstractclassAbstractPreAndPostProcessingAuthenticationHandler
implementsAuthenticateHandler{
protectedLoglog=LogFactory.getLog（this.getClass（））;
protectedbooleanpreAuthenticate（finalCredentialscredentials）{
returntrue;
}
protectedbooleanpostAuthenticate（finalCredentialscredentials,
finalbooleanauthenticated）{
returnauthenticated;
}
publicfinalbooleanauthenticate（finalCredentialscredentials）
throwsAuthenticationException{
if（!
preAuthenticate（credentials））{
returnfalse;
}
finalbooleanauthenticated=doAuthentication（credentials）;
returnpostAuthenticate（credentials,authenticated）;
}
protectedabstractbooleandoAuthentication（finalCredentialscredentials）
throwsAuthenticationException;
}
AbstractPreAndPostProcessingAuthenticationHandler类新定义了preAuthenticate（）方法和postAuthenticate（）方法，而实际的认证工作交由doAuthentication（）方法来执行。
因此，如果需要在认证前后执行一些额外的操作，可以分别扩展preAuthenticate（）和ppstAuthenticate（）方法，而doAuthentication（）取代authenticate（）成为了子类必须要实现的方法。
由于实际运用中，最常用的是用户名和密码方式的认证，CAS3提供了针对该方式的实现，如清单3所示：
清单3.AbstractUsernamePasswordAuthenticationHandler定义
publicabstractclassAbstractUsernamePasswordAuthenticationHandlerextends
AbstractPreAndPostProcessingAuthenticationHandler{
...
protectedfinalbooleandoAuthentication（finalCredentialscredentials）
throwsAuthenticationException{
returnauthenticateUsernamePasswordInternal（（UsernamePasswordCredentials）credentials）;
}
protectedabstractbooleanauthenticateUsernamePasswordInternal（
finalUsernamePasswordCredentialscredentials）throwsAuthenticationException;
protectedfinalPasswordEncodergetPasswordEncoder（）{
returnthis.passwordEncoder;
}
publicfinalvoidsetPasswordEncoder（finalPasswordEncoderpasswordEncoder）{
this.passwordEncoder=passwordEncoder;
}
...
}
基于用户名密码的认证方式可直接扩展自AbstractUsernamePasswordAuthenticationHandler，验证用户名密码的具体操作通过实现authenticateUsernamePasswordInternal（）方法达到，另外，通常情况下密码会是加密过的，setPasswordEncoder（）方法就是用于指定适当的加密器。
从以上清单中可以看到，doAuthentication（）方法的参数是Credentials类型，这是包含用户认证信息的一个接口，对于用户名密码类型的认证信息，可以直接使用UsernamePasswordCredentials，如果需要扩展其他类型的认证信息，需要实现Credentials接口，并且实现相应的CredentialsToPrincipalResolver接口，其具体方法可以借鉴UsernamePasswordCredentials和UsernamePasswordCredentialsToPrincipalResolver。
JDBC认证方法
用户的认证信息通常保存在数据库中，因此本文就选用这种情况来介绍。
将前面下载的cas-server-3.1.1-release.zip包解开后，在modules目录下可以找到包cas-server-support-jdbc-3.1.1.jar，其提供了通过JDBC连接数据库进行验证的缺省实现，基于该包的支持，我们只需要做一些配置工作即可实现JDBC认证。
JDBC认证方法支持多种数据库，DB2,Oracle,MySql,MicrosoftSQLServer等均可，这里以DB2作为例子介绍。
并且假设DB2数据库名：
CASTest，数据库登录用户名：
db2user，数据库登录密码：
db2password，用户信息表为：
userTable，该表包含用户名和密码的两个数据项分别为userName和password。
1.配置DataStore
打开文件%CATALINA_HOME%/webapps/cas/WEB-INF/deployerConfigContext.xml，添加一个新的bean标签，对于DB2，内容如清单4所示：
清单4.配置DataStore
com.ibm.db2.jcc.DB2Driver
jdbc:
db2:
//9.125.65.134:
50000/CASTest
db2user
db2password
其中id属性为该DataStore的标识，在后面配置AuthenticationHandler会被引用，另外，需要提供DataStore所必需的数据库驱动程序、连接地址、数据库登录用户名以及登录密码。
2.配置AuthenticationHandler
在cas-server-support-jdbc-3.1.1.jar包中，提供了3个基于JDBC的AuthenticationHandler，分别为BindModeSearchDatabaseAuthenticationHandler,QueryDatabaseAuthenticationHandler,SearchModeSearchDatabaseAuthenticationHandler。
其中BindModeSearchDatabaseAuthenticationHandler是用所给的用户名和密码去建立数据库连接，根据连接建立是否成功来判断验证成功与否；QueryDatabaseAuthenticationHandler通过配置一个SQL语句查出密码，与所给密码匹配；SearchModeSearchDatabaseAuthenticationHandler通过配置存放用户验证信息的表、用户名字段和密码字段，构造查询语句来验证。
使用哪个AuthenticationHandler，需要在deployerConfigContext.xml中设置，默认情况下，CAS使用一个简单的username=password的AuthenticationHandler，在文件中可以找到如下一行：
AuthenticationHandler"/>，我们可以将其注释掉，换成我们希望的一个AuthenticationHandler，比如，使用QueryDatabaseAuthenticationHandler或SearchModeSearchDatabaseAuthenticationHandler可以分别选取清单5或清单6的配置。
清单5.使用QueryDatabaseAuthenticationHandler
value="selectpasswordfromuserTablewherelower（userName）=lower（?
）"/>
清单6.使用SearchModeSearchDatabaseAuthenticationHandler
class="org.jasig.cas.adaptors.jdbc.SearchModeSearchDatabaseAuthenticationHandler"
abstract="false"singleton="true"lazy-init="default"
autowire="default"dependency-check="default">
userTable
<
升级会员 