集成框架中使用CAS实现单点登录技术方案

1、集成框架中使用CAS实现单点登录技术方案1、文档摘要31.1 文档分类31.2 关键字31.3 使用SSO的最终目的31.4 摘要31.5 参考31.6 修改历史42、技术方案5问题或场景5.webSSO的原理5CAS的基本原理6CAS协议7配置一个基本的CAS8准备工作8配置CAS服务器8配置jboss服务器使用https协议9.配置cas客户端.10测试SSO1.3扩展认证接口及与数据库结合验证13.如何做扩展部署14如何获取登录的用户名2Q.3、问题或不足214、改进意见215、附件211、文档摘要文档分类技术方案-关于单点登录关键字SSQYaleCAS使用SSO的最终目的1、实现一个易

2、用的、能跨不同Web应用的单点登录认证中心；2、实现统一的用户身份和密钥管理，减少多套密码系统造成的管理成本和安全漏洞；3、降低认证模块在IT系统设计中的耦合度，提供更好的SOA设计和更弹性的安全策略摘要本文描述如何实现多应用系统下的单点登录具体实现方案参考YaleCAS网站(http:/tp/cas/)及网络相关技术文档1.5修改历史日期版本作者修改内容评审号更改请求号2008-6-181.0许建飞创建2、技术方案问题或场景假设目前有多个WEB应用系统，采用不同的语言开发，部署在不同的服务器上；每个系统分别管理着自己的用户。那么，客户在使用不同系统时就必须在不同的系统

3、之间切换，反复的输入不同的用户名和密码。在系统集成时如何使用户只需要认证一次就能登入各个不同的系统？那么就必须采用用户身份集中管理、统一认证，这就涉及到单点登录（singlesign-onSSO）勺问题了。webSSO的原理WebSSO主要特点是，SSO应用之间走Web协议（如HTTP/SSL）,并且SSO都只有一个登录入口。j简单的SSO的体系中，会有下面三种角色：User（多个）Web应用（多个）SSO认证中心（1个）虽然SSO实现模式千奇百怪，但万变不离其宗：1、Web应用不处理User的登录，否则就是多点登陆了，所有的登录都在SSO认证中心进行。2、SSO认证中心通过一些方法来告诉We

4、b应用当前访问用户究竟是不是张三/李四3、SSO认证中心和所有的Web应用建立一种信任关系，SSO认证中心对用户身份正确性的判断会通过某种方法告之Web应用，而且判断结果必须被Web应用信任。CAS的基本原理从结构体系看，CAS包含两部分：CASServerCASServer负责完成对用户的认证工作，CASServer需要独立部署，有不止一种CASServer的实现，YaleCASServe环口ESUPCASServer都是很不错的选择。CASServer会处理用户名/密码等凭证(Credentials),它可能会到数据库检索一条用户帐号信息，也可能在XML文件中检索用户密码，对这种方式，CA

5、S均提供一种灵活但同一的接口/实现分离的方式，CAS究竟是用何种认证方式，跟CAS协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。CASClientCASClient负责部署在客户端(注意，我是指Web应用)，原则上，CASClient的部署意味着，当有对本地Web应用的受保护资源的访问请求，并且需要对请求方进行身份认证，Web应用不再接受任何的用户名密码等类似的Credentials,而是重定向到CASServer进行认证。目前，CASClient支持（某些在完善中）非常多的客户端，包括Java、.Net、ISAPI、Php、Perl、uPortal、Acegi、Ruby、VBS

6、cript等客户端，几乎可以这样说，CAS协议能够适合任何语言编写的客户端应用。CAS协议CASClient与受保护的客户端应用部署在一起，以Filter方式保护受保护的资源。对于访问受保护资源的每个Web请求，CASClient会分析该请求的Http请求中是否包含ServiceTicket,如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的CASServer登录地址，并传递Service（也就是要访问的目的资源地址），以便登录成功过后转回该地址。用户在第3步中输入认证信息，如果登录成功，CASServer随机产生一个相当长度、唯一、不可伪造的ServiceTicket并缓存以待将来

7、验证，之后系统自动重定向到Service所在地址，并为客户端浏览器设置一个TicketGrantedCookie(TGC),CASClient在拿到Service和新产生的Ticket过后，在第5,6步中与CASServer进行身份合适，以确保ServiceTicket的合法性。在该协议中，所有与CAS的交互均采用SSL协议，确保，ST和TGC的安全性。协议工作过程中会有2次重定向的过程，但是CASClient与CASServer之间进行Ticket验证的过程对于用户是透明的。另外，CAS协议中还提供了Proxy(代理)模式，以适应更加高级、复杂的应用场景配置一个基本的CAS准备工作下载测试用

8、的web应用服务器apache-tomcat-6.0.16jboss-4.2.2.GA下载cas-server-3.2.1-releasecas-client-2.0.11.zip本文通过以上版本举例说明。配置CAS服务器假设将CASserver端部署在jboss下，其他几个客户端应用系统分别在tomcat或者jboss下。由于CAS使用Https协议，所以首先要知道如何在jboss容器中配置SSL.;CAS勺客户端以一个Web应用的Filter运行。当Web应用的某个功能被请求时，Filter就会拦截应用的URL,从而迫使用户到CAS服务器进行登陆。在所有不同的Web应用中，使用同一个CAS

9、服务器进行登陆，即可达到单点登陆之目的。将cas-server-3.2.1-release.Zp压，找至Ucas-server-3.2.1-release/cas-server-3.2.1/modules/cas-server-webapp-3.2.1.waS续解压它。加解压后的文件夹cas-server-webapp-3.2改名为cas.war为了发布到jboss下方便，tomcat下直接用这个war压缩包就行了），启动jboss服务，测试CAS服务器是否发布正常，可以访问http:/localhost:8080/cas/login出现登陆窗口。输入用户名密码（用户名=密码），出现登陆成功页

10、面说明发布正常。配置jboss服务器使用https协议1、使用Java自带的keytool命令，产生SERVER的证书D:">keytool-genkey-aliasmy-alias-name-keyalgRSA-keystorekeystore-file其中my-alias-name为别名，这行命令的作用是产生一个新的公共/私有钥匙对。keystore-file为存储钥匙和证书的文件。命令运行后，根据提示回答。注意在开始问“你的名字”或“DName”的时候，必须填写你服务器所在域名（在局域网中测试时，使用主机名或hosts文件中注册的域名，本机可以使用localhost）。2

11、、至U这个目录下去找server.xml文件打开，相应位置更改如下:<Connectorport="8443"protocol="HTTP/1.1"SSLEnabled="true"maxThreads="150"scheme="https"secure="true"clientAuth="false"sslProtocol="TLS"keystoreFile="D:/keystore-file"keystor

12、ePass="*"/>其中，keystoreFile使用绝对路径或相对路径(如$jboss.server.home.dir/7.),keystorePas的第3点输入的keystore密码。3、配置完成后，启动就jboss访问https:/localhost:8443,访问成功说明SSL配置成功。也可以访问https:/localhost:8443/cas/login配置cas客户端以Tomcat中自带的example甑用为例，在Web应用中使用配置CAS客户端。1、在examples应用里配置CAS客户端，需修改examples/WEB-INF/web.xml,在w

13、eb.xml文件中，力口入如下Filter配置<filter><filter-name>CASFilter</filter-name><filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class><init-param><param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name><param-value>https:/localhos

14、t:8443/cas/login</param-value></init-param><init-param><param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name><param-value>https:/localhost:8443/cas/serviceValidate</param-value></init-param><init-param><param-name>edu.yale.i

15、ts.tp.cas.client.filter.serverName</param-name><param-value>localhost:8080</param-value></init-param></filter><filter-mapping><filter-name>CASFilter</filter-name><url-pattern>/*</url-pattern></filter-mapping>其中，第一，二个localhost都改成CAS服务器

16、域名或主机名，第三个改成你serveltexample5用域名或主机名，由于本文中CAS服务器与客户端在同一主机同一Tomcat上，所以都为localhost若不在同一主机，则分别使用两主机的域名或主机名。详细说明如下：表格1.CASFilter必需的参数参数名作用edu.yale.its.tp.cas.client.filter.loginUrl指定CAS提供登录页面的URLedu.yale.its.tp.cas.client.filter.validateUrl指定CAS提供serviceticket或proxyticket验证服务的URLedu.yale.its.tp.cas.clien

17、t.filter.serverName指定客户端的域名和端口，是指客户端应用所在机器而不是CASServer所在机器，该参数或serviceUrl至少有一个必须指定edu.yale.its.tp.cas.client.filter.serviceUrl该参数指定过后将覆盖serverName参数，成为登录成功过后重定向的目的地址表格2.CASFilter可选参数参数名作用xyCallbackUrl用于当前应用需要作为其他服务的代理（proxy）时获取ProxyGrantingTicket的地址edu.yale.its.t

18、p.cas.client.filter.authorizedProxy用于允许当前应用从代理处获取proxytickets,该参数接受以空格分隔开的多个proxyURLs，但实际使用只需要一个成功即可。当指定该参数过后，需要修改validateUrl至UproxyValidate,而不再是serviceValidateedu.yale.its.tp.cas.client.filter.renew如果指定为true,那么受保护的资源每次被访问时均要求用户重新进行验证，而不管之前是否已经通过edu.yale.its.tp.cas.client.filter.wrapRequest如果指定为true

19、,那么CASFilter将重新包装HttpRequest,并且使getRemoteUser（）方法返回当前登录用户的用户名edu.yale.its.tp.cas.client.filter.gateway指定gateway属性2、将cas-client-2.0.11.zi廨压,把java/lib/casclient.jar拷贝至1Tomcat的webapps/examples/WEB-INF/lib目录下（如果没有就建一个）3、执行命令行，导出SERVER的证书，用来给所有需要用到的客户端导入D:">keytool-export-filemyserver.cert-aliasm

20、y-alias-name-keystorekeystore-file4、执行命令行，在客户端的JVM里导入信任的SERVER的证书，（假设你的另外一个应用系统也是用的java,这一步是必须的，否则不能建立两者之间的信任关系。如果不执行下面的命令行，比如在.net环境下可以考虑将生成的myserver.ce柞为IE的证书倒入浏览器看看，需要再试一下）D:">keytool-import-keystore$JAVA_HOME/jre/lib/security/cacerts-filemyserver.cert-aliasmy-alias-name其中，$JAVA_HOME改成JDK

21、的绝对路径。路径当中如果有空格用双引号括起来。输入keystore密码时，注意现在的keystore为cacerts而cacerts的初密码为changeit而不是前面keystore-file的密码，所以要是没有改过cacerts密码应该输入changeit.测试SSO启动Tomcat和jboss,访问http:/localhost:8080/servlets-examples/,随便执行一个servlet,系统会自动跳转到一个验证页面，随便输入一个相同的账号，密码，认证通过之后，就会访问到你点击的servlet了。扩展认证接口及与数据库结合验证CASServer负责完成对用户的认证工作，它

22、会处理登录时的用户凭证(Credentials)信息，用户名/密码对是最常见的凭证信息。CASServer可能需要到数据库检索一条用户帐号信息，也可能在XML文件中检索用户名/密码，还可能通过LDAPServer获取等，在这种情况下，CAS提供了一种灵活但统一的接口和实现分离的方式，实际使用中CAS采用哪种方式认证是与CAS的基本协议分离开的，用户可以根据认证的接口去定制和扩展。如何做扩展部署扩展AuthenticationHandlerCAS提供扩展认证的核心是AuthenticationHandler接口，具体可查阅源码，看下面一段demo代码，扩展认证方法publicclassUsern

23、ameLengthAuthnHandlerextendsAbstractUsernamePasswordAuthenticationHandlerprotectedbooleanauthenticateUsernamePasswordInternal(UsernamePasswordCredentialscredentials)throwsAuthenticationException/*这里我们完全可以用自己的认证逻辑代替，比如将用户名/密码传入一个SQL语句，向数据库验证是否有对应的用户账号，只需要将下面的程序替换掉就OK了！/Stringusername=credentials.getU

24、sername();Stringpassword=credentials.getPassword();StringcorrectPassword=Integer.toString(username.length();returncorrectPassword.equals(password);完了记得在deployerConfigContext.xm中把这个bea尬册一下,就可用了。另外，查看该xml文件发现注册bean时是一个list,如下：<list><beanclass="org.jasig.cas.authentication.handler.support

25、.HttpBasedServiceCredentialsAuthenticationHandler"p:httpClient-ref="httpClient"/><!下面就是系统默认的验证器配置，你可以替换它，或者增加一个新的handler-><beanclass="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler"/></list>在这个list中可以配置多个Auth

26、enticationHandlers这些AuthenticationHandlers形成了一个验证器链，所有提交给CAS的Credentials信息将通过这个验证器链的链式过滤，只要这链中有一个验证器通过了对Credentials勺验证，就认为这个Credentials合法的。这样的设计使得我们可以很轻松的整合不同验证体系的已有应用到同一个CAS上，比如：A验证器负责校验alpha系统提交的Credentials它是基于LDAP服务器的；B验证器负责校验beta系统提交的Credentials它是一个传统的RDB用户表认证；C验证器负责校验gamma系统提交的基于RSA证书加密的Credent

27、ials3种完全不同的用户身份认证通过配置就可以统一在同一个CAS服务内JDBC认证方法用户的认证信息通常保存在数据库中，因此本文就选用这种情况来介绍。将前面下载的cas-server-3.1.1-release.zip解开后，在modules目录下可以找到包cas-server-support-jdbc-3.1.1.ja其提供了通过JDBC连接数据库进行验证的缺省实现，基于该包的支持，我们只需要做一些配置工作即可实现JDBC认证。JDBC认证方法支持多种数据库，DB2,Oracle,MySql,MicrosoftSQLServer等均可，这里以oraclelO作为例子介绍。并且假设oracl

28、eSID为：mytest,数据库登录用户名：mytest,数据库登录密码:oracle,用户信息表为：app_useg该表包含用户名和密码的两个数据项分别为userName和password如下：我们测试使用的是oracle数据库，可以选用任何一个支持JDBC的数据库。用scott/tiger登陆sqlplus输入如下语句创建用户表和输入测试数据：createtableapp_user(usernamevarchar(100),passwordvarchar(100);insertintoapp_uservalues('tomcat','tomcat');ins

29、ertintoapp_uservalues('cas','cas');commit;打开deployerConfigContext.xm文件，开始配置.配置DataStore<!-add配置数据库联接-><beanid="dataSource"class="org.springframework.jdbc.datasource.DriverManagerDataSource"destroy-method="close"><propertyname="driverC

30、lassName"><value>oracle.jdbc.driver.OracleDriver</value></property><propertyname="url"><value>jdbc:oracle:thin::1521:mytest</value></property><propertyname="username"><value>mytest</value></property&g

31、t;<propertyname="password"><value>oracle</value></property></bean><!-addend->.酉己置AuthenticationHandler在cas-server-support-jdbc-3.1.1.j葩中，提供了3个基于JDBC的AuthenticationHandler,分另U为BindModeSearchDatabaseAuthenticationHandler,QueryDatabaseAuthenticationHandler,

32、SearchModeSearchDatabaseAuthenticationHancUe其中BindModeSearchDatabaseAuthenticationHandler是用所给的用户名和密码去建立数据库连接，根据连接建立是否成功来判断验证成功与否；QueryDatabaseAuthenticationHandle通过酉己置个SQL语句查出密码，与所给密码匹配；SearchModeSearchDatabaseAuthenticationHandler®过配置存放用户验证信息的表、用户名字段和密码字段，构造查询语句来验证。使用哪个AuthenticationHandler,需要

33、在deployerConfigContext.xml中设置，默认情况下，CAS使用一个简单的username=password的AuthenticationHandler（就是第2.5章节所谈到的配置），在文件中可以找到如下一行：<beanclass="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler"/>,我们可以将其注释掉，换成我们希望的一个AuthenticationHandler,比如，使用QueryDatabaseAu

34、thenticationHandler或SearchModeSearchDatabaseAuthenticationHandler可以分别选取下面两个清单的配置。使用QueryDatabaseAuthenticationHandler<beanclass="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler"><propertyname="sql"value="selectpasswordfromapp_userwhereusername=?"

35、/><propertyname="dataSource"ref="dataSource"/><bean>使用SearchModeSearchDatabaseAuthenticationHandler1IIII<beanid="SearchModeSearchDatabaseAuthenticationHandler"Iiclass="org.jasig.cas.adaptors.jdbc.SearchModeSearchDatabaseAuthenticationIHandler"

36、;abstract="false"singleton="true"lazy-init="defa3t”IIautowire="default"dependency-check="default”>I<propertyname="tableUsers”>I;<value>app_user</value></property>i<propertyname="fieldUser”>i<value>userName</v

37、alue>I</property>i<propertyname=''fieldPassword"><value>password</value></property>1<propertyname="dataSource"ref="casDataSource”/>i</bean>另外，由于存放在数据库中的密码通常是加密过的，所以AuthenticationHandler在匹配时需要知道使用的加密方法，在deployerConfigContext.xml

38、文件中我们可以为具体的AuthenticationHandler类配置个property,指定力口密器类，比如对于QueryDatabaseAuthenticationHandler,可以修改所示：添力口passwordEncoder<beanclass="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler"><propertyname="dataSource"ref="casDataSource"/><propertyname=&

39、quot;sql"value="selectpasswordfromapp_userwherelower(userName)=lower(?)"/><propertyname="passwordEncoder"ref="myPasswordEncoder"/></bean>其中myPasswordEncoder是对如下清单中设置的实际加密器类的引用:指定具体加密器类这里MyPasswordEncoder是根据实际情况自己定义的加密器，实现PasswordEncoder接口及其encode()方法。熟悉spring的人应该相当对上面的配置感到很亲切，因为CAS3也已经aop,配置都是基于SPRING的方式。4、部署依赖包在以上配置完成以后，需要拷贝几个依赖的包到cas应用下，包括：?将cas-server-supp