CAS单点登录配置全过程
CAS配置全过程说明:这里只是简单的配置了CAS单点登录的过程，并没有加入复杂的验证，也没有做MD5的校验。
输入数据库中存在的用户名跟密码就会登录成功一．首先需要下载cas-server-3.4.2-release.zip包，这个包里面包含CAS Server服务器的war包。
解压之后放到找到cas-server-3.4.2\modules 下的cas-server-webapp-3.4.2.war , 拷tomcat\webapps\下并改名为cas.war。
启动tomcat后会在webapps下看到cas文件，然后停止tomcat.二. 配置tomcat以及修改cas server的配置1.生成证书并导入到jdk的jre中请直接运行附件中的.bat文件会自动把证书生成在D盘根目录下并导入到jre 中这是bat脚本内容keytool -genkey -alias tomcatgecko -keyalg RSA -keystore d:\mykeystore -dname "CN=gecko-4d4611f2e, OU=gecko-4d4611f2e, O=gecko-4d4611f2e, L=SH, ST=SH, C=CN"-keypass changeit -storepass changeitkeytool -export -alias tomcatgecko -keystore d:\mykeystore -file d:\mycerts.crt -storepass changeitkeytool -import -keystore "%JAVA_HOME%/JRE/LIB/SECURITY/CACERTS" -file d:\mycerts.crt -alias tomcatgecko这里要注意：证书是要导入到tomcat使用的jdk。
不然CAS在跳转时会找不到本地域名脚本中红色的部分是写自己的计算机名称然后在C:\WINDOWS\system32\drivers\etc\hosts配置自己的本地域名,跟计算机名称相同2.启动tomcat之后会在tomcat\webapps下看到cas.war解压出来之后的cas文件夹;找到tomcat\conf\server.xml文件。
在xml中加入<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"port="8443" minSpareThreads="5" maxSpareThreads="75"enableLookups="true" disableUploadTimeout="true"acceptCount="100" maxThreads="200"scheme="https" secure="true" SSLEnabled="true"clientAuth="false" sslProtocol="TLS"keystoreFile="D:\mykeystore"keystorePass="changeit"/>keystoreFile=”” 是指定证书的路径keystorePass=”” 是证书的密码3. 修改cas server 服务器配置打到cas\WEB-INF\deployerConfigContext.xml注释掉<!--<beanclass="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthentic ationHandler" />-->加入<bean class="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler"><property name="sql" value="select password from portal_user where username=?" /><property name="dataSource" ref="dataSource"/></bean>红色部分是sql语句，可以根据自己的需求修改修改后文件如下:<?xml version="1.0" encoding="UTF-8"?><!--| deployerConfigContext.xml centralizes into one file some of the declarative configuration that| all CAS deployers will need to modify.|| This file declares some of the Spring-managed JavaBeans that make up a CAS deployment.| The beans declared in this file are instantiated at context initialization time by the Spring| ContextLoaderListener declared in web.xml. It finds this file because this| file is among those declared in the context parameter "contextConfigLocation".|| By far the most common change you will need to make in this file is to change the last bean| declaration to replace the default SimpleTestUsernamePasswordAuthenticationHandler with| one implementing your approach for authenticating usernames and passwords.+--><beans xmlns="/schema/beans"xmlns:xsi="/2001/XMLSchema-instance"xmlns:p="/schema/p"xmlns:sec="/schema/security"xsi:schemaLocation="/schema/beans /schema/beans/spring-beans-3.0.xsd/schema/security/schema/security/spring-security-3.0.xsd"><!--| This bean declares our AuthenticationManager. The CentralAuthenticationService service bean| declared in applicationContext.xml picks up this AuthenticationManager by reference to its id,| "authenticationManager". Most deployers will be able to use the default AuthenticationManager| implementation and so do not need to change the class of this bean. We include the whole| AuthenticationManager here in the userConfigContext.xml so that you can see the things you will| need to change in context.+--><bean id="authenticationManager"class="org.jasig.cas.authentication.AuthenticationManagerImpl"><!--| This is the List of CredentialToPrincipalResolvers that identify what Principal is trying to authenticate.| The AuthenticationManagerImpl considers them in order, finding a CredentialToPrincipalResolver which| supports the presented credentials.|| AuthenticationManagerImpl uses these resolvers for two purposes. First, it uses them to identify the Principal| attempting to authenticate to CAS /login . In the default configuration, it is the DefaultCredentialsToPrincipalResolver| that fills this role. If you are using some other kind of credentials than UsernamePasswordCredentials, you will need to replace| DefaultCredentialsToPrincipalResolver with a CredentialsToPrincipalResolver that supports the credentials you are| using.|| Second, AuthenticationManagerImpl uses these resolvers to identify a service requesting a proxy granting ticket.| In the default configuration, it is the HttpBasedServiceCredentialsToPrincipalResolver that serves this purpose.| You will need to change this list if you are identifying services by something more or other than their callback URL.+--><property name="credentialsToPrincipalResolvers"><list><!--| UsernamePasswordCredentialsToPrincipalResolver supports the UsernamePasswordCredentials that we use for /login| by default and produces SimplePrincipal instances conveying the username from the credentials.|| If you've changed your LoginFormAction to use credentials other than UsernamePasswordCredentials then you will also| need to change this bean declaration (or add additional declarations) to declare a CredentialsToPrincipalResolver that supports the| Credentials you are using.+--><beanclass="ernamePasswordCredentialsToPrincipalResolv er" /><!--| HttpBasedServiceCredentialsToPrincipalResolver supports HttpBasedCredentials. It supports the CAS 2.0 approach of| authenticating services by SSL callback, extracting the callback URL from the Credentials and representing it as a| SimpleService identified by that callback URL.|| If you are representing services by something more or other than an HTTPS URL whereat they are able to| receive a proxy callback, you will need to change this bean declaration (or add additional declarations).+--><beanclass="org.jasig.cas.authentication.principal.HttpBasedServiceCredentialsToPrincipalResolver " /></list></property><!--| Whereas CredentialsToPrincipalResolvers identify who it is some Credentials might authenticate,| AuthenticationHandlers actually authenticate credentials. Here we declare the AuthenticationHandlers that| authenticate the Principals that the CredentialsToPrincipalResolvers identified. CAS will try these handlers in turn| until it finds one that both supports the Credentials presented and succeeds in authenticating.+--><property name="authenticationHandlers"><list><!--| This is the authentication handler that authenticates services by means of callback via SSL, thereby validating| a server side SSL certificate.+--><beanclass="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticati onHandler"p:httpClient-ref="httpClient" /><!--| This is the authentication handler declaration that every CAS deployer will need to change before deploying CAS| into production. The defaultSimpleTestUsernamePasswordAuthenticationHandler authenticates UsernamePasswordCredentials| where the username equals the password. You will need to replace this with an AuthenticationHandler that implements your| local authentication strategy. You might accomplish this by coding a new such handler and declaring| edu.someschool.its.cas.MySpecialHandler here, or you might use one of the handlers provided in the adaptors modules.+--><!--<beanclass="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthentic ationHandler" />--><beanclass="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler"><property name="sql" value="select password from app_user where username=?" /> <property name="dataSource" ref="dataSource" /></bean></list></property></bean><!--This bean defines the security roles for the Services Management application. Simple deployments can use the in-memory version.More robust deployments will want to use another option, such as the Jdbc version.The name of this should remain "userDetailsService" in order for Spring Security to find it.To use this, you should add an entry similar to the following between the two value tags:battags=notused,ROLE_ADMINwhere battags is the username you want to grant access to. You can put one entry per line.--><sec:user-service id="userDetailsService"><sec:user name="@@THIS SHOULD BE REPLACED@@" password="notused"authorities="ROLE_ADMIN" /></sec:user-service><!--Bean that defines the attributes that a service may return. This example uses the Stub/Mock version. A real implementationmay go against a database or LDAP server. The id should remain "attributeRepository" though.--><bean id="attributeRepository"class="org.jasig.services.persondir.support.StubPersonAttributeDao"><property name="backingMap"><map><entry key="uid" value="uid" /><entry key="eduPersonAffiliation" value="eduPersonAffiliation" /><entry key="groupMembership" value="groupMembership" /></map></property></bean><!--Sample, in-memory data store for the ServiceRegistry. A real implementationwould probably want to replace this with the JPA-backed ServiceRegistry DAOThe name of this bean should remain "serviceRegistryDao".--><beanid="serviceRegistryDao"class="org.jasig.cas.services.InMemoryServiceRegistryDaoImpl" /><bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"><propertyname="driverClassName"><value>com.mysql.jdbc.Driver</value></property> <propertyname="url"><value>jdbc:mysql://localhost:3306/portal</value></property><property name="username"><value>portal</value></property><property name="password"><value>portal</value></property></bean></beans>找到cas\WEB-INF\spring-configuration\ticketGrantingTicketCookieGenerator.xml并修改成<?xml version="1.0" encoding="UTF-8"?><beans xmlns="/schema/beans"xmlns:xsi="/2001/XMLSchema-instance"xmlns:p="/schema/p"xsi:schemaLocation="/schema/beans /schema/beans/spring-beans-2.0.xsd"><description>Defines the cookie that stores the TicketGrantingTicket. You most likely should never modify these (especially the "secure" property).You can change the name if you want to make it harder for people to guess.</description><bean id="ticketGrantingTicketCookieGenerator"class="org.jasig.cas.web.support.CookieRetrievingCookieGenerator"p:cookieSecure="false"p:cookieMaxAge="-1"p:cookieName="CASTGC"p:cookiePath="/cas" /></beans>红色部分代表修改过的地方说明：请在附件中把cas-server-3.4.2-release.zip解压后找到cas-server-3.4.2\modules\cas-server-support-jdbc-3.4.2.jar,把它拷贝到cas\WEB-INF\lib下；还要把数据库驱动拷贝进来(看用的是什么数据库)。
CAS单点登录配置全过程
CAS配置全过程软件工具：1.cas-server-3.3.5-release.zip（CAS服务端）2.cas-client-3.1.10-release.zip（CAS客户端）3.apache-tomcat-7.0.40mons-dbcp-all-1.3-r699049.jar5.mysql-connector-java-5.1.18-bin.jar6.cas-server-jdbc-3.0.5-rc2.jar写在前面的话此配置是根据当前系统，当前的版本，仅供参考，如果有什么其他的问题可以一起研究。
第一节：先走通技术障碍第一步：环境部署1.在Tomcat 根目录下创建一个cas目录。
2.下载CAS服务器并解压，打开cas-server-3.3.5\modules，将cas-server-webapp-3.3.5.war复制到刚刚在Tomcat创建的cas目录下，并重命名为ROOT.war3.修改host文件（C:\Windows\System32\drivers\etc）添加127.0.0.1 注意：如果想在一台PC机上模拟这个单点登录，就必须域名重定向，如果是多台ＰＣ机，可以不配置此项，下文有用到，可以用相应ＰＣ机的ＩＰ代替4.修改Tomcat文件下的server.xml（apache-tomcat-7.0.40\conf\server.xml）添加内容：<Host name="" appBase="cas"unpackWARs="true" autoDeploy="true"></Host>5.启动Tomcat服务，查看信息，（如果有报错，可以根据信息查找错误），打开浏览器，输入:8080如果出现以下界面，则CAS服务端配置成功。
注：这个是最简单的CAS服务，只要输入的用户名跟密码一样，就可以正常登陆，在我们实际开发中，这个验证因为跟数据库作比较，接下来，我们就配置数据库校验。
CAS示例环境部署及配置完整版
C A S示例环境部署及配置一、示例说明在本示例中将使用cas-server-3.5.0和cas-client-3.2.1搭建一个SSO测试环境;在同一台机器上安装3个tomcat;分别部署一个casserver和两个casclient;这三个应用使用不同的域名访问通过配置hosts文件实现多个域名..配置完成之后;应达到如下效果：1、首先访问app1;此时需要跳转到cas登录页面;要求用户进行登录；2、输入正确的用户名和密码;登录成功之后自动跳转到app1;而且可以获取到用户的登录信息；3、在同一个浏览器中直接访问app2;此时不需要再次用户登录即可正常访问;而且可以获取到登录用户的信息；4、反复访问app1和app2;只要不关闭浏览器;就可以一直正常访问并且可以获取到用户信息；5、在浏览器地址栏输入CAS登出的路径;系统提示成功注销；6、此时无论访问app1还是app2;都会跳转到cas登录页面;要求用户重新登录..二、部署文件清单三、准备部署环境本文演示过程在同一个机器上的也可以在三台实体机器或者三个的虚拟机上;根据演示需求;我们需要准备三个不同的域名;分别对应casserver和两个cas客户端应用;用修改hosts文件的方法添加域名最简单方便这个非常重要;在文件c:\windows\system32\drivers\etc\hosts文件中添加三条cas.demoapp1.demodemo其中：对应部署casserver的tomcat;如果这个tomcat使用https协议;则这个虚拟域名还用于证书生成；另外两个域名对应两个不同的客户端应用..安装JDK;配置JAVA_HOME、PATH环境变量；在D盘根目录复制三个TOMCAT文件夹;分别命名为tomcat-for-cas、tomcat-for-client-1、tomcat-for-client-2；这个详细过程就不再详细描述..四、CASSERVER部署及通用配置3.1CASSERVER部署cas-server-xxxx.war的下载地址为;本文以cas-server-3.5.0.zip为例;解压提取cas-server-3.5.0/modules/cas-server–webapp-3.5.0.war文件;把此文件复制到tomcat-for-cas\webapps目录并解压到cas文件夹如果不准备对CAS的文件做修改;则可以直接将WAR文件修改为cas.war即可..启动tomcat此tomcat的默认监听端口为8090;在浏览器地址栏输入：ht;按回车键后地址栏会自动变为;并显示如下界面：在登录窗口中;用户名和密码都输入admin实际上可以输入任何值;只要用户名和密码一致;就可以成功登录;这个是CAS的默认验证规则;然后点击登录;会出现如下界面：至此;CASSERVER的应用已经部署成功;接下来就是根据情况进行配置..3.2CASSERVER通用配置1.配置CASSERVER节点名称在文件${CAS}/WEB-INF/cas.properties中的值;比如修改为cas01..2.去除登录页面的“Non-secureConnection”提示如果部署CASSERVER的TOMCAT没有启用HTTPS或者没有通过HTTPS端口访问;则会出现如下提示;想要去掉这个提示;只能修改登录页面..五、CAS客户端的部署及配置4.1客户端应用的部署按照常规方式部署使用CAS作为单点登录服务器的应用;并测试此应用是否能正常访问;我们使用的是一个测试应用;只有一个jsp页面;将这个应用放到准备好的tomcat-for-client-2/webapps下面即可;访问应用的跟目录;如果显示正常的页面即表示应用部署成功;我的测试应用显示如下信息：4.2复制CASCLIENT需要的JAR文件复制CAS核心文件和其所依赖的JAR;不同版本的CAS需要的JAR文件可能稍微有所不同;本例使用的是cas-client-core-3.2.1;需要的JAR文件如下所示：4.3配置web.xml文件有关cas-client的web.xml修改的详细说明见官网介绍：我们这里只介绍将会用到的最简单的配置;将如下内容复制到web.xml中;需要注意的是SingleSignOutFilter的映射一定要写在其他过滤器的最前面;至少是过滤器CASAuthenticationFilter的前面;然后根据实际情况修改参数即可;如下所示突出显示的部分：4.4部署结果测试配置完成后;启动CASSERVER所在的tomcat和CAS客户端所在的tomcat;然后打开浏览器输入网址;此时浏览器会自动进行跳转到CAS的登录页面;地址栏会显示如下的地址：;同时会看到如下所示的登录界面：在登录窗口中;用户名和密码都输入admin;然后点击登录;系统会自动跳转到登录之前我们要访问的地址;出现如下界面：至此;一个简单的CAS测试环境就搭建成功了..六、为CASSERVER配置HTTPS5.1获取安全证书通常可以从一些安全机构申请安全证书;但是要支付一定的费用;在本试验中;我们使用JDK自带的工具keytool生成一个证书;生成证书的命令为：在上面的命令行中;突出显示的部分为需要修改的部分;其他参数可以默认;也可以参照keytool的参数说明进行修改；其中参数alias指定了证书的别名;以后对证书的操作会用到此名称;我们这里设置为cas;keystore指定了证书存在磁盘上的文件路径;即我们需要将生成的证书存放在哪里..创建证书的过程如下所示;需要注意的是途中画红方框的地方;这个值需要与访问cas 时的域名或者cas所在的计算机名保持一致；最后一个密码和keystore的密码保持一致即可;密码是casserver..5.2配置CASSERVER使用的TOMCAT默认情况下;tomcat是没有开启https端口的;因此需要在TOMCAT/conf/server.xml中进行手动配置..首先找到如下代码的位置：在配置文件中添加红框中所示的代码;其中keystoreFile为我们生成的证书文件的存放路径;keystorePass为生成证书时输入的密码;本实验中我把证书文件复制到了server.xml 的目录下..5.3通过HTTPS访问CAS应用在浏览器中输入;出现如下所示的界面：点击“继续浏览此网站”即可跳转到我们熟悉的登录界面;此时你会发现;那个令人讨厌的“Non-secureConnection”提示也没有了：在登录窗口中;用户名和密码都输入admin实际上可以输入任何值;只要用户名和密码一致;就可以成功登录;这个是CAS的默认验证规则;然后点击登录;会出现如下界面5.4修改CAS客户端的配置将CAS客户端的web.xml中需要配置CASSERVERURL的地方做对应的修改;本例中;应将过滤器CASAuthenticationFilter的参数casServerLoginUrl的值由“/login”修改为“/login”；将过滤器CASValidationFilter的参数casServerUrlPrefix的值由“”修改为“”；修改完配置文件之后;重新启动tomcat;访问地址;浏览器依然会自动跳转到登录页面;但是当输入完用户名和密码;点击登录之后;就会出现如下的错误页面：上图对应的错误信息如下：出现这个错误的直接原因就是因为JVM没有找到访问时所需要的安全证书;现在出现这个错误是正常的;因为我们还没有将安全证书导入到JVM的证书库中;如果在以后的使用过程中出现这个错误;可以通过keytool的list命令查看JVM的证书库中是否有对应的证书.. 5.5为运行CASCLIENT的JVM设置安全证书CAS客户端在验证时;会从后台通过代码访问CASSERVER;此时是通过HTTPS进行访问的;因此运行CAS客户端的JVM会在JVM的证书库中查找与访问的域名对应的证书;然后使用此证书与CASSERVER建立会话..因此我们要告诉JVM到哪里获取安全证书..有两种方法可以达到这个目的;一个方法是在启动TOMCAT的时候为JVM指定证书的位置和访问密码;另一个方法是将安全证书导入到JVM的默认证书库中..1、为JVM指定可信证书库的位置在启动TOMCAT的启动参数中增加如下内容;也可以在启动TOMCAT之前将环境变量JAVA_OPTS设置为如下的值需要注意的是下面两行的内容不要换行：有两种方式指定JVM的启动参数;一种在tomcat/bin/catalina.bat中指定：一种是单独建一个文件;比如start-with-key.bat;然后在文件中加入下面的内容：修改完启动脚本之后;重新启动tomcat;访问地址;浏览器依然会自动跳转到登录页面;输入完用户名和密码;点击登录之后;就会自动跳转到我们需要访问的地址;并显示正常的页面..2、将安全证书导入到JVM默认的证书库中如果在启动JVM的时候没有指定安全证书的位置;当程序用到安全证书时;JVM将使用JRE默认的证书库;位置为%JAVA_HOME%\jre\lib\security\cacerts..因此我们需要做的就是将CASSERVER使用的安全证书导入到JRE的这个证书库中..首先使用keytool的export命令将keystore中的证书信息导出为cer格式的文件;命令格式为：keytool-export-aliascas-keystorecas.keystore-filecas.cer;其中keystore 指定了CASSERVERS使用的安全证书文件的路径我们前面生成的证书存放的路径;参数file 指定要将证书信息导出到哪个文件进行存放..本例中使用的是tomcat/conf下的证书文件;同时也将导出的证书放在了这个目录下：然后使用keytool的import命令将证书cas.cer中的信息导入到JVM的证书库中;命令格式为：keytool-import-aliascas-keystore“%JAVA_HOME%\jre\lib\security\cacerts”-filec as.cer;其中keystore指定了JVM的安全证书文件的路径;参数file指定要将哪个证书的信息导入..JVM证书库的默认密码是changeit..如果在导入证书时;提示证书已经存在;则使用keytool的delete命令将证书删除后再导入即可;命令的语法为keytool-delete-aliascas-keystore“%JAVA_HOME%\jre\lib\security\cacerts”..查看证书是否导入成功：确认证书导入成功之后;重新启动tomcat记得去掉指定安全证书库的启动参数呦;不然是看不到效果的;访问地址;浏览器依然会自动跳转到登录页面;输入完用户名和密码;点击登录之后;就会自动跳转到我们需要访问的地址;并显示正常的页面..至此;一个简单的CAS测试环境就搭建好了;既可以通过HTTP端口访问;也可以通过HTTPS 端口访问..。
CAS客户端服务器端配置步骤
CAS客户端服务器端配置步骤cas介绍：CAS 是Yale 大学发起的一个开源项目，旨在为Web 应用系统提供一种可靠的单点登录方法，CAS 在2004 年12 月正式成为JA-SIG 的一个项目。
CAS 具有以下特点：∙开源的企业级单点登录解决方案。
∙CAS Server 为需要独立部署的Web 应用。
∙支持非常多的客户端(这里指单点登录系统中的各个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单点登录服务器的部署以及使用
CAS单点登录服务器的部署以及使用一．准备CAS服务器端和客户端1.Windows下a)cas服务器端压缩包cas-server-3.4.12-release.zipb)cas客户端压缩包cas-client-3.2.1-release.zip官网有下载/2.linux下a)cas服务器端压缩包cas-server-3.4.12-release.tar.gzb)cas客户端压缩包cas-client-3.2.1-release.tar.gz官网有下载/二．准备架包Oracle数据库驱动架包ojdbc6.jar三．安装CAS1.重新安装一个服务器，如tomcat。
2.部署CAS项目a)解压缩cas-server-3.4.12-release.(tar.gz/zip)，进入解压后的cas-server-3.4.12-release目录下的modules中，取出cas-server-webapp-3.4.12.war，放入新安装的tomcat目录下的webapp下，修改war包的名字为cas.war，启动tomcat,将cas.war解压到webapp下，然后关闭服务器3.CAS服务器端证书相关操作。
a)生成服务器端证书Linux下命令：keytool -genkey -alias mycas -keyalg RSA -keystore/home/XXX/cas/key/mycas.keystorewindows下命令：keytool -genkey -alias mycas -keyalg RSA -keystore D\cas\key\mycas.keystore 有效期默认是三个月，若需要修改，增加一个参数，-validity,单位：天b)导出证书Linux下命令：keytool -export -trustcacerts -file /home/XXX/cas/key/mycas.crt -alias mycas -keystore /home/XXX/cas/key/mycas.keystorec)导入证书到客户端JDKLinux下命令：keytool -import -trustcacerts -keystore$JAVA_HOME/jre/lib/security/cacerts -file/home/XXX/cas/key/mycas.crt -alias mycas -storepass changeitwindows下命令:keytool -import -trustcacerts-keystore %JAVA_HOME\jre\lib\security\cacerts -fileD:\cas\key\mycas.crt -alias mycas -storepass changeitd)如果生成失败，请删除证书，重新导入删除证书文件cas/key下的两个文件后执行将证书从jdk中移除，移除JDK中的证书命令Linux下命令：keytool -delete -alias mycas -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeitwindow下命令：--移除JDK中的证书keytool -delete -alias mycas -keystore %JAVA_HOME\jre\lib\security\cacerts-storepass changeite)生成jssecacerts文件下载InstallCert.java这个java源文件网址:/code/snippet_12_4092在命令行中编译，然后执行java文件javac InstallCert.javajava InstallCert localhost:8080将生成的jssecacerts文件复制到$JAVA_HOME\jre\lib\security 目录下f)开启服务器端Tomcat的SSLg)重启电脑登陆测试服务器端,地址为https://localhost:8845/cas，登录用户名密码相同h)查看证书keytool -list -keystore/home/ligang/jdk1.6.0_26/jre/lib/security/cacerts -storepasschangeit4.修改CAS服务器配置，使其可以与项目结合a)进入解压出来的cas目录的WEB-INF下，b)将cas-server-3.4.12-release\modules下的cas-server-support-jdbc-3.4.12.jar和ojdbc6.jar复制到WEB-INF\lib下c)使用编辑工具打开deployerConfigContext.xmld)有三种登录配置，默认是SimpleTestUsernamePasswordAuthenticationHandler，用户名密码相同即可，QueryDatabaseAuthenticationHandler采用在配置文件中指定SQL语句的方式，SearchModeSearchDatabaseAuthenticationHandler是可以在类中写方法的方式。
CAS单点登录HTTP协议版本配置指南
CAS单点登录配置配置(HTTP协议版本)一、CAS版本：服务端是cas-server-3.4.7。
这里不需要源代码，解压zip包中的cas-server-webapp-3.4.7.war 出来即可。
客户端是cas-client-3.2.0。
这里主要用到cas-client-core-3.2.0.jar包，当然在后面如果需要用到，可自行添加。
Apache的日志包这里常用的包是需要的。
二、环境搭建Tomcat6.x + JDK6.x关于搭建基本环境，网上已经一大把：官方WIKI：https:///display/CASUM/HomeIBM技术社区：/developerworks/cn/opensource/os-cn-cas/ITeye技术社区：/topic/544899还有很多就不列举了。
总体来说，使用Http协议的CAS比Https版本的步骤少了ssl的配置，然后在服务端需要修改部分配置文件即可。
基本上的配置是大同小异的，下面就详细记录下来，日后参考。
三、部署配置环境搭建完毕后，按下面的步骤，按部就班走完下面的步骤即可1.CAS服务端配置。
服务端主机名假定为。
(1).端口配置。
我们不使用8443，直接使用80端口，这样看上去舒服点。
进入部署CAS服务端的Tomcat的conf目录下，配置service.xml即可，主要代码如下：...<Connector port="80" protocol="HTTP/1.1"connectionTimeout="20000"redirectPort="8443" URIEncoding="gbk"/>...<Engine name="Catalina" defaultHost=""><Host name="" appBase="webapps"unpackW ARs="true" autoDeploy="true"xmlValidation="false" xmlNamespaceAware="false"><Context path="" debug="0" docBase="G:/projects//web" reloadable="true" /></Host>...</Engine>...注意到这里之际设置默认的主机是了，另外我将下载下来的cas-server-webapp-3.4.7.war解压到Eclipse中的一个工程中去了（G:/projects//web 目录下），同时把docBase指向该工程的目录下，这样可以随时在IDE中修改配置文件，比用普通的文本编辑器编辑配置文件方便很多。
SSO之CAS单点登录详细搭建
SSO之CAS单点登录详细搭建：环境说明：同一个机器上环境如下：操作系统：windows7 64位JDK版本：1.7.0_80web容器版本：apache-tomcat-7.0.70 64位服务端：cas-3.5.2.1.zip服务端现在地址：https:///apereo/cas/archive/v4.2.3.zip客户端：cas-client-3.3.3-release.zip客户端下载地址：/cas-clients/eclipse版本：eclipse-jee-luna-SR2-win32-x86_64.zip1、将cas-3.5.2.1 cas-client-3.3.3 标准maven工程导入eclipse 打包编译；2、修改本机C:\Windows\System32\drivers\etc\hosts (CAS单点登录系统是基于JAVA安全证书的https 访问，要使用CAS单点登录必须要配置域名, cas是不能通过ip访问的.)附件-->记事本管理员权限编辑hosts文件，加入如下三行代码后保存。
127.0.0.1 127.0.0.1 127.0.0.1 解释： =>> 对应部署cas server的tomcat，这个虚拟域名还用于服务端证书生成 =>> 对应部署client1客户端应用的tomcat =>> 对应部署client2客户端应用的tomcat3、安全证书配置3.1、管理员模式打开cmd命令窗口，生成证书，在cmd窗口输入以下命令：C:\Users\Administrator>keytool -genkey -alias ssoflyer -keyalg RSA -keysize 1024 -keypass flyer2016 -validity 365 -keystore D:\app\flyer.keystore -storepass flyer2016说明：-alias自定义的别名；-keypass指定证书密钥库的密码；-storepass和前面keypass密码相同,否则下面tomcat配置https会访问失败；-keystore指定证书的位置,例如：D:\app\目录,密钥库名称可以自定义，例如：flyer.keystore特别注意：您的名字与姓氏是什么？该项一定要使用网站的域名，例如: ，Cas Client使用httpclient访问cas server的时候，会严格的检查证书。
CAS单点登录系列
小蚂蚁-CAS单点登录系列(1)-基础知识1.单点登录1.1.概述单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。
SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
1.2.技术实现机制当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性。
如果通过效验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
1.3.要实现SSO需要以下主要的功能所有应用系统共享一个身份认证系统；所有应用系统能够识别和提取ticket信息；应用系统能够识别已经登录过的用户，能自动判断当前用户是否登录过，从而完成单点登录的功能。
其中，统一的身份认证系统最重要，认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。
另外，认证系统还应该对ticket进行效验，判断其有效性。
整个系统可以存在两个以上的认证服务器，这些服务器甚至可以是不同的产品。
认证服务器之间要通过标准的通讯协议，互相交换认证信息，就能完成更高级别的单点登录。
2.数字签名2.1.概念数字签名（又称公钥数字签名、电子签章）是一种类似写在纸上的普通的物理签名，但是使用了公钥加密领域的技术实现，用于鉴别数字信息的方法。
一套数字签名通常定义两种互补的运算，一个用于签名，另一个用于验证。
2.2.主要功能保证信息传输的完整性、发送者的身份认证、防止交易中的抵赖发生。
数字签名技术是将摘要信息用发送者的私钥加密，与原文一起传送给接收者。
cas单点登录系统：客户端（client）详细配置
cas单点登录系统：客户端（client）详细配置最近⼀直在研究cas登录中⼼这⼀块的应⽤，分享⼀下记录的⼀些笔记和⼼得。
后⾯会把cas-server端的配置和重构，另外还有这⼏天再搞nginx+cas的https反向代理配置，以及cas的证书相关的知识分享出来。
Cas由两部分组成，Cas Server和Cas Client。
Cas Server是Cas⾃⼰的服务端，⽽Cas Client是Cas客户端，往往客户端需要和我们具体的业务系统进⾏集成，这⾥我们主要详述cas 客户端的配置以及实例第⼀步：我们得有⼀个现成的web项⽬，然后我们要加⼊cas-client-core-xxx.jar到classpath；maven项⽬⽤这个：<dependency><groupId>org.jasig.cas.client</groupId><artifactId>cas-client-core</artifactId><version>3.3.3</version></dependency>第⼆步：配置Filter我们需要在应⽤的web.xml⽂件中配置四个Filter，这四个Filter必须按照固定的顺序来进⾏配置，⽽且它们必须配置在应⽤的其它Filter之前。
它们的先后顺序要求如下：1、AuthenticationFilter2、TicketValidationFilter3、HttpServletRequestWrapperFilter4、AssertionThreadLocalFilter1.1、 配置AuthenticationFilter1.1.1、AuthenticationFilter有两个必须指定的参数：casServerLoginUrl⽤来指定Cas Server登录地址，serverName或service⽤来指定认证成功后需要跳转地址。
cas单点登录配置速成
cas单点登录配置速成服务端配置cas是个好东西，很灵活很好用，但是配置起来很麻烦，网上资料比较零碎。
不弄个三五天根本不知道其中的原理，终于在多天的奋斗中配置成功，现在将配置的一些过程记录下来供大家参考。
cas官方网站/cas下载最新的服务端CAS Server 3.3.3 Final解压后将modules下面的cas-server-webapp-3.3.3.war部署到web服务器，作为单点登录的服务器。
登录的服务器下面很多配置文件，通过配置可以做一些扩展。
修改点1：验证方式使用我们自己的用户表验证cas和当前已有的系统做集成的入口1.修改deployerConfigContext.xml文件添加数据源配置XML/HTML代码1.<bean id="casDataSource" class="mons.dbcp.BasicDataSource">2. <property name="driverClassName">3. <value>com.m ysql.jdbc.Driver</value>4. </property>5. <property name="url">6. <value>jdbc:m ysql://192.168.1.100/ires?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true</value>7. </property>8. <property name="username">9. <value>ires</value>10. </property>11. <property name="password">12. <value>i709394</value>13. </property>14.</bean>定义MD5的加密方式XML/HTML代码1.<bean id="passwordEncoder"2. class="org.jasig.cas.authentication.handler.DefaultPasswordEncoder" autowire="byName">3. <constructor-arg value="MD5"/>4.</bean>配置authenticationManager下面的authenticationHandlers属性XML/HTML代码1.<bean class="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler">2. <property nam e="dataSource" ref="casDataSource" />3. <property nam e="sql" value="select community_password from community_user_info where lower(community_user_munity_user) = lower(?)" />4. <property nam e="passwordEncoder" ref="passwordEncoder"/>5.</bean>修改点2：获取用户信息保存，方便各个客户端可以统一得到用户信息1.定义attributeRepository，通过jdbc查询用户的详细信息，可以把用户表或用户的所属组织机构或角色等查询出来。
CAS单点登录（五）——Service配置及管理
CAS单点登录（五）——Service配置及管理CAS单点登录(五)——Service配置及管理在上⼀节我们讲述了CAS中关于⾃定义认证登录策略，对CAS中关于⾃定义登录配置的⽅案，校验策略有了⼀定的了解，如果忘记了可以去复习⼀下——————CAS单点登录(四)——⾃定义认证登录策略。
这节本来该介绍⾃定义表单信息的知识，但是考虑到使⽤⾃定义表单知识涉及到Service配置⽅⾯的知识，所以这⼀节介绍⼀下在CAS中Service配置及管理。
⾸先我们要明⽩CAS中的Service的概念是什么，我们在第⼀节就讲解了在CAS系统中，主要分为三部分，User、Web应⽤、SSO认证中⼼。
User就是我们普通⽤户，Web应⽤就是需要接⼊SSO认证中⼼的应⽤也就是这⾥的Service，⽽SSO认证中⼼就是CAS服务端。
简单来说就是CAS分为服务端和客户端，⽽Service就是指具体的多个客户端（CAS Clients）。
⽽这⾥的服务管理（Service Management）就是CAS服务管理⼯具允许CAS服务器管理员声明和配置哪些服务（Service，CAS客户端）可以在哪些⽅⾯使⽤CAS。
服务管理⼯具的核⼼组件是服务注册表，它存储⼀个或多个注册服务。
接下来先介绍我们的第⼀个知识点——Service配置！⼀、Service配置我们刚刚提及到在CAS中，服务管理⼯具中的服务注册表当中存储着⼀个或多个注册服务，⽽这些Service中包含着各个⾏为的元数据，通过配置这些数据我们可以控制这些Service的⾏为。
主要⾏为包括⼀些⼏点：授权服务 - 控制哪些服务可以参与CAS SSO会话。
强制⾝份验证 - 为强制⾝份验证提供管理控制。
属性发布 - 为服务提供⽤户详细信息以进⾏授权和个性化。
代理控制 - 通过授予/拒绝代理⾝份验证功能进⼀步限制授权服务。
主题控制 - 定义⽤于特定服务的备⽤CAS主题。
在Service中配置属性主要包括以下这些信息：上图介绍了⼀些在Service中常⽤的配置项，对于各个配置属性的含义可以参考具体⽂档，服务配置。