集成框架中使用CAS实现单点登录技术方案.docx
《集成框架中使用CAS实现单点登录技术方案.docx》由会员分享，可在线阅读，更多相关《集成框架中使用CAS实现单点登录技术方案.docx（17页珍藏版）》请在冰豆网上搜索。
集成框架中使用CAS实现单点登录技术方案
集成框架中使用CAS实现单点登录
技术方案
1、文档摘要
1.1文档分类
技术方案---关于单点登录
1.2关键字
SSO、YaleCAS
1.3使用SSO的最终目的
1、实现一个易用的、能跨不同Web应用的单点登录认证中心；
2、实现统一的用户身份和密钥管理，减少多套密码系统造成的管理成本和安全漏洞；
3、降低认证模块在IT系统设计中的耦合度，提供更好的SOA设计和更弹性的安全策略
1.4摘要
本文描述如何实现多应用系统下的单点登录具体实现方案
1.5参考
YaleCAS网站（http:
//www.yale.edu/tp/cas/）及网络相关技术文档
1.5修改历史
日期
版本
作者
修改内容
评审号
更改请求号
2008-6-18
1.0
许建飞
创建
2、技术方案
2.1问题或场景
假设目前有多个WEB应用系统，采用不同的语言开发，部署在不同的服务器上；每个系统分别管理着自己的用户。
那么，客户在使用不同系统时就必须在不同的系统之间切换，反复的输入不同的用户名和密码。
在系统集成时如何使用户只需要认证一次就能登入各个不同的系统？
那么就必须采用用户身份集中管理、统一认证，这就涉及到单点登录（singlesign-onSSO）的问题了。
2.2webSSO的原理
WebSSO主要特点是，SSO应用之间走Web协议（如HTTP/SSL），并且SSO都只有一个登录入口。
j
简单的SSO的体系中，会有下面三种角色：
1User（多个）
2Web应用（多个）
3SSO认证中心（1个）
虽然SSO实现模式千奇百怪，但万变不离其宗：
1、Web应用不处理User的登录，否则就是多点登陆了，所有的登录都在SSO认证中心进行。
2、SSO认证中心通过一些方法来告诉Web应用当前访问用户究竟是不是张三/李四。
3、SSO认证中心和所有的Web应用建立一种信任关系，SSO认证中心对用户身份正确性的判断会通过某种方法告之Web应用，而且判断结果必须被Web应用信任。
2.3CAS的基本原理
从结构体系看，CAS包含两部分：
●CASServer
CASServer负责完成对用户的认证工作，CASServer需要独立部署，有不止一种CASServer的实现，YaleCASServer和ESUPCASServer都是很不错的选择。
CASServer会处理用户名/密码等凭证（Credentials），它可能会到数据库检索一条用户帐号信息，也可能在XML文件中检索用户密码，对这种方式，CAS均提供一种灵活但同一的接口/实现分离的方式，CAS究竟是用何种认证方式，跟CAS协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。
●CASClient
CASClient负责部署在客户端（注意，我是指Web应用），原则上，CASClient的部署意味着，当有对本地Web应用的受保护资源的访问请求，并且需要对请求方进行身份认证，Web应用不再接受任何的用户名密码等类似的Credentials，而是重定向到CASServer进行认证。
目前，CASClient支持（某些在完善中）非常多的客户端，包括Java、.Net、ISAPI、Php、Perl、uPortal、Acegi、Ruby、VBScript等客户端，几乎可以这样说，CAS协议能够适合任何语言编写的客户端应用。
2.4CAS协议
CASClient与受保护的客户端应用部署在一起，以Filter方式保护受保护的资源。
对于访问受保护资源的每个Web请求，CASClient会分析该请求的Http请求中是否包含ServiceTicket，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的CASServer登录地址，并传递Service（也就是要访问的目的资源地址），以便登录成功过后转回该地址。
用户在第3步中输入认证信息，如果登录成功，CASServer随机产生一个相当长度、唯一、不可伪造的ServiceTicket，并缓存以待将来验证，之后系统自动重定向到Service所在地址，并为客户端浏览器设置一个TicketGrantedCookie（TGC），CASClient在拿到Service和新产生的Ticket过后，在第5，6步中与CASServer进行身份合适，以确保ServiceTicket的合法性。
在该协议中，所有与CAS的交互均采用SSL协议，确保，ST和TGC的安全性。
协议工作过程中会有2次重定向的过程，但是CASClient与CASServer之间进行Ticket验证的过程对于用户是透明的。
另外，CAS协议中还提供了Proxy（代理）模式，以适应更加高级、复杂的应用场景
2.5配置一个基本的CAS
2.5.1准备工作
下载测试用的web应用服务器apache-tomcat-6.0.16，jboss-4.2.2.GA；
下载cas-server-3.2.1-release、cas-client-2.0.11.zip；
本文通过以上版本举例说明。
2.5.2配置CAS服务器
假设将CASserver端部署在jboss下，其他几个客户端应用系统分别在tomcat或者jboss下。
由于CAS使用Https协议，所以首先要知道如何在jboss容器中配置SSL.;CAS的客户端以一个Web应用的Filter运行。
当Web应用的某个功能被请求时，Filter就会拦截应用的URL，从而迫使用户到CAS服务器进行登陆。
在所有不同的Web应用中，使用同一个CAS服务器进行登陆，即可达到单点登陆之目的。
将cas-server-3.2.1-release.zip解压，找到cas-server-3.2.1-release/cas-server-3.2.1/modules/cas-server-webapp-3.2.1.war，继续解压它。
加解压后的文件夹cas-server-webapp-3.2.1改名为cas.war（为了发布到jboss下方便，tomcat下直接用这个war压缩包就行了），启动jboss服务，测试CAS服务器是否发布正常，可以访问http:
//localhost:
8080/cas/login出现登陆窗口。
输入用户名密码（用户名＝密码），出现登陆成功页面说明发布正常。
2.5.3配置jboss服务器使用https协议
1、使用Java自带的keytool命令，产生SERVER的证书
D:
">keytool-genkey-aliasmy-alias-name-keyalgRSA-keystorekeystore-file
其中my-alias-name为别名，这行命令的作用是产生一个新的公共/私有钥匙对。
keystore-file为存储钥匙和证书的文件。
命令运行后，根据提示回答。
注意在开始问“你的名字”或“DName”的时候，必须填写你服务器所在域名（在局域网中测试时，使用主机名或hosts文件中注册的域名,本机可以使用localhost）。
2、到jboss-4.2.2.GA\server\default\deploy\jboss-web.deployer\这个目录下去找server.xml文件打开，相应位置更改如下：
其中，keystoreFile使用绝对路径或相对路径（如${jboss.server.home.dir}/…/...），keystorePass为第3点输入的keystore密码。
3、配置完成后，启动就jboss访问https:
//localhost:
8443，访问成功说明SSL配置成功。
也可以访问https:
//localhost:
8443/cas/login
2.5.4配置cas客户端
以Tomcat中自带的examples应用为例，在Web应用中使用配置CAS客户端。
1、在examples应用里配置CAS客户端，需修改examples/WEB-INF/web.xml，在web.xml文件中,加入如下Filter配置
CASFilter
edu.yale.its.tp.cas.client.filter.CASFilter
edu.yale.its.tp.cas.client.filter.loginUrl
https:
//localhost:
8443/cas/login
edu.yale.its.tp.cas.client.filter.validateUrl
https:
//localhost:
8443/cas/serviceValidate
edu.yale.its.tp.cas.client.filter.serverName
localhost:
8080
CASFilter
/*
其中，第一，二个localhost都改成CAS服务器域名或主机名，第三个改成你serveltexample应用域名或主机名，由于本文中CAS服务器与客户端在同一主机同一Tomcat上，所以都为localhost。
若不在同一主机，则分别使用两主机的域名或主机名。
详细说明如下：
表格1.CASFilter必需的参数
参数名
作用
edu.yale.its.tp.cas.client.filter.loginUrl
指定CAS提供登录页面的URL
edu.yale.its.tp.cas.client.filter.validateUrl
指定CAS提供serviceticket或proxyticket验证服务的URL
edu.yale.its.tp.cas.client.filter.serverName
指定客户端的域名和端口，是指客户端应用所在机器而不是CASServer所在机器，该参数或serviceUrl至少有一个必须指定
edu.yale.its.tp.cas.client.filter.serviceUrl
该参数指定过后将覆盖serverName参数，成为登录成功过后重定向的目的地址
表格2.CASFilter可选参数
参数名
作用
edu.yale.its.tp.cas.client.filter.proxyCallbackUrl
用于当前应用需要作为其他服务的代理（proxy）时获取ProxyGrantingTicket的地址
edu.yale.its.tp.cas.client.filter.authorizedProxy
用于允许当前应用从代理处获取proxytickets，该参数接受以空格分隔开的多个proxyURLs，但实际使用只需要一个成功即可。
当指定该参数过后，需要修改validateUrl到proxyValidate，而不再是serviceValidate
edu.yale.its.tp.cas.client.filter.renew
如果指定为true，那么受保护的资源每次被访问时均要求用户重新进行验证，而不管之前是否已经通过
edu.yale.its.tp.cas.client.filter.wrapRequest
如果指定为true，那么CASFilter将重新包装HttpRequest,并且使getRemoteUser（）方法返回当前登录用户的用户名
edu.yale.its.tp.cas.client.filter.gateway
指定gateway属性
2、将cas-client-2.0.11.zip解压，把java/lib/casclient.jar拷贝到Tomcat的webapps/examples/WEB-INF/lib目录下（如果没有就建一个）
3、执行命令行，导出SERVER的证书，用来给所有需要用到的客户端导入
D:
">keytool-export-filemyserver.cert-aliasmy-alias-name-keystorekeystore-file
4、执行命令行，在客户端的JVM里导入信任的SERVER的证书，（假设你的另外一个应用系统也是用的java，这一步是必须的，否则不能建立两者之间的信任关系。
如果不执行下面的命令行，比如在.net环境下可以考虑将生成的myserver.cert作为IE的证书倒入浏览器看看，需要再试一下）
D:
">keytool-import-keystore$JAVA_HOME/jre/lib/security/cacerts-filemyserver.cert-aliasmy-alias-name
其中，$JAVA_HOME改成JDK的绝对路径。
路径当中如果有空格用双引号括起来。
输入keystore密码时，注意现在的keystore为cacerts，而cacerts的初密码为changeit，而不是前面keystore-file的密码，所以要是没有改过cacerts密码应该输入changeit.
2.5.5测试SSO
启动Tomcat和jboss，访问http:
//localhost:
8080/servlets-examples/，随便执行一个servlet，系统会自动跳转到一个验证页面，随便输入一个相同的账号,密码，认证通过之后，就会访问到你点击的servlet了。
2.6扩展认证接口及与数据库结合验证
CASServer负责完成对用户的认证工作，它会处理登录时的用户凭证（Credentials）信息，用户名/密码对是最常见的凭证信息。
CASServer可能需要到数据库检索一条用户帐号信息，也可能在XML文件中检索用户名/密码，还可能通过LDAPServer获取等，在这种情况下，CAS提供了一种灵活但统一的接口和实现分离的方式，实际使用中CAS采用哪种方式认证是与CAS的基本协议分离开的，用户可以根据认证的接口去定制和扩展。
2.6.1如何做扩展部署
扩展AuthenticationHandler
CAS提供扩展认证的核心是AuthenticationHandler接口，具体可查阅源码，看下面一段demo代码，扩展认证方法
完了记得在deployerConfigContext.xml中把这个bean注册一下，就可用了。
另外，查看该xml文件发现注册bean时是一个list,如下：
在这个list中可以配置多个AuthenticationHandlers。
这些AuthenticationHandlers形成了一个验证器链，所有提交给CAS的Credentials信息将通过这个验证器链的链式过滤，只要这链中有一个验证器通过了对Credentials的验证，就认为这个Credentials是合法的。
这样的设计使得我们可以很轻松的整合不同验证体系的已有应用到同一个CAS上，比如：
A验证器负责校验alpha系统提交的Credentials，它是基于LDAP服务器的；B验证器负责校验beta系统提交的Credentials，它是一个传统的RDB用户表认证；C验证器负责校验gamma系统提交的基于RSA证书加密的Credentials。
3种完全不同的用户身份认证通过配置就可以统一在同一个CAS服务内
JDBC认证方法
用户的认证信息通常保存在数据库中，因此本文就选用这种情况来介绍。
将前面下载的cas-server-3.1.1-release.zip包解开后，在modules目录下可以找到包cas-server-support-jdbc-3.1.1.jar，其提供了通过JDBC连接数据库进行验证的缺省实现，基于该包的支持，我们只需要做一些配置工作即可实现JDBC认证。
JDBC认证方法支持多种数据库，DB2,Oracle,MySql,MicrosoftSQLServer等均可，这里以oracle10作为例子介绍。
并且假设oracleSID为：
mytest，数据库登录用户名：
mytest，数据库登录密码：
oracle，用户信息表为：
app_user，该表包含用户名和密码的两个数据项分别为userName和password。
如下：
我们测试使用的是oracle数据库，可以选用任何一个支持JDBC的数据库。
用scott/tiger登陆sqlplus,输入如下语句创建用户表和输入测试数据：
createtableapp_user（usernamevarchar（100）,passwordvarchar（100））;
insertintoapp_uservalues（'tomcat','tomcat'）;
insertintoapp_uservalues（'cas','cas'）;
commit;
打开deployerConfigContext.xml文件，开始配置
1.配置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（就是第2.5章节所谈到的配置），在文件中可以找到如下一行：
，我们可以将其注释掉，换成我们希望的一个AuthenticationHandler，比如，使用QueryDatabaseAuthenticationHandler或SearchModeSearchDatabaseAuthenticationHandler可以分别选取下面两个清单的配置。
使用QueryDatabaseAuthenticationHandler
" />
使用SearchModeSearchDatabaseAuthenticationHandler
class="org.jasig.cas.adaptors.jdbc.SearchModeSearchDatabaseAuthenticationHandler"
abstract="false"singleton="true"lazy-init="default"
autowire="default"dependency-check="default">
app_user
userName
password
另外，由于存放在数据库中的密码通常是加密过的，所以AuthenticationHandler在匹配时需要知道使用的加密方法，在deployerConfigContext.xml文件中我们可以为具体的AuthenticationHandler类配置一个property，指定加密器类，比如对于QueryDatabaseAuthenticationHandler，可以修改所示：
添加passwordEncoder
升级会员 