门户技术学习笔记之单点登录.docx
《门户技术学习笔记之单点登录.docx》由会员分享，可在线阅读，更多相关《门户技术学习笔记之单点登录.docx（20页珍藏版）》请在冰点文库上搜索。
门户技术学习笔记之单点登录
门户技术学习笔记_单点登录
门户技术学习笔记_单点登录1
1前言2
2SSO前提2
2.1统一用户管理2
2.2统一认证3
3SSO常见解决方案4
4邮政实行SSO需求分析4
5SSO产品研究5
5.1CAS5
5.1.1简介5
5.1.2CAS结构体系5
5.1.3CAS协议6
5.1.4安全性7
5.1.5应用实践8
5.1.5.1下载文件版本8
5.1.5.2Server端部署9
5.1.5.2.1SSL方式9
5.1.5.2.2非SSL方式10
5.1.5.3Client端部署10
5.1.5.4认证接口实现12
5.1.5.4.1数据库13
5.1.5.4.2LDAP14
5.1.5.5CAS单点退出15
5.1.5.6扩展CAS界面16
5.1.5.7应用系统改造17
5.1.5.7.1改造要点17
5.1.5.7.2致发框架改造实现18
5.1.5.7.3门户单点登录场景应用18
5.2JOSSO19
1前言
根据各种业务信息水平的需要构建的应用系统，这些应用系统是在不同的时期开发完成的，各应用系统由于功能侧重、设计方法和开发技术都有所不同，也就形成了各自独立的用户库和用户认证体系。
随着业务应用系统的不断增加，用户不断收藏各业务系统的访问地址，系统使用时不断反复登录，影响工作效率，影响业务信息化带来的快捷性和高效性。
此外，多个应用平台有多个用户管理，各系统的用户维护工作非常繁琐。
特别是随着局内对应用系统安全规范的发布，对用户管理和认证都有较高的要求，因此建立一套统一的单点登录系统（引伸为统一门户系统）具有切实的实际意义。
2SSO前提
单点登录的英文名称为SingleSign-On，简写为SSO，它是一个用户认证的过程，允许用户一次性进行认证之后，就访问系统中不同的应用；而不需要访问每个应用时，都重新输入密码。
IBM对SSO有一个形象的解释“单点登录、全网漫游”。
实现SSO的有两大前提，分别是统一用户管理和统一认证，其中统一用户管理又是实现统一认证的基础。
2.1统一用户管理
移动和电信都已实现了统一用户管理，邮政做为类似的集团性公司，对组织机构内所有应用实行统一的用户信息的存储和管理。
统一用户管理要遵循以下两个基本原则：
Ø统一性原则：
实现对目前已知用户类型进行统一管理；对包括分支机
在内的整个组织机构内的所有用户进行用户目录复制和统一管理；对
户的用户体系和各应用系统各自独立的用户体系进行统一管理；对员工的加入和离开进行整个生命周期的管理。
Ø可扩充性原则：
能够适应对将来扩充子系统的用户进行管理。
统一的用户信息存储可基于：
Ø数据库方式：
支持将统一的用户信息存储于各大主流数据库中，如Oracle、DB2、SQLServer、Sybase、MySQL等；对于邮政，一般选择Oracle。
ØLDAP目录方式：
支持将统一的用户信息存储于LDAP目录中，主流LDAP服务器如DominoLDAP、SunOneDirectoryServer、OpenLDAP、MSActiveDirectory、NovellNDS、NetscapeDirectoryServer等。
SunOneDirectoryServer有企业版，有免费版可用；OpenLDAP为开源LDAP实现。
统一用户管理不是本学习笔记的重点，网上一篇文章讲解得很好。
参考：
2.2统一认证
单点登录，在狭义上将就是统一认证，商业的和开源的统一认证产品都很多，本文对单点登录研究的主要内容在统一认证。
一般说来，统一认证体系中，至少包含如下三种角色：
ØUser（多个）
ØWeb应用（多个）
ØSSO认证中心（1个）
虽然SSO实现模式千奇百怪，但万变不离其宗：
ØWeb应用不处理User的登录，否则就是多点登陆了，所有的登录都在SSO认证中心进行。
ØSSO认证中心通过一些方法来告诉Web应用当前访问用户究竟是不是张三/李四。
ØSSO认证中心和所有的Web应用建立一种信任关系，SSO认证中心对用户身份正确性的判断会通过某种方法告之Web应用，而且判断结果必须被Web应用信任。
3SSO常见解决方案
Ø基于domain的方案
原理：
应用A在，B在，如果设cookie的时候，设domain为，那在A、B上都可以访问到这个cookie了。
（cookie的domain、path、port、version、secure相同）。
该方案特点：
1、不能够跨域
2、在网络中传送用户名和密码
3、只支持J2EE应用
Ø基于gateway的方案
实际部署的时候，对所有应用的请求，都要通过一个gateway转发一下，比如用一个L4的交换机顶在前面
Ø基于tooken传递的方案
主要是以耶鲁大学的CAS项目为基础。
具体的应用看不到用户的密码。
由CAS执行授权，只有CAS能看到用户的密码。
这样增加发安全性，因为用户名和密码不会通过网络在应用间传播。
ØUSBKey登录
用户都有一个USBKey证书，在登陆系统的时候把这个证书插在计算机上。
每一个网站都要通过这个证书去认证。
4邮政实行SSO需求分析
当前我们的业务系统存在以下特点：
Ø基本为B/S结构系统，绝大多数为J2EE应用。
Ø使用具体IP地址访问应用，没有采用域名绑定。
B/S应用系统实现单点单独，其实是一种WEBSSO，即WEB-SSO是体现在客户端。
另外一种SSO是桌面SSO，例如，只需要作为Administrator登录一次windows2000，便能够在使用MSN/QQ的时候免去登录的环节（注意，这不是用客户端软件的密码记忆功能），是一种代理用户输入密码的功能。
因此，桌面SSO是体现在OS级别上。
因此，邮政实现单点登录，基本上就是实现WEBSSO，其主要特点是，SSO应用之间走Web协议（如HTTP/SSL），并且SSO都只有一个登录入口。
此外，目前应用系统地址没有采取域名绑定，IP地址难以记忆，也不利于地址变动，最好采取规范的应用域名管理，当然，一个好的SSO产品也支持IP绑定，对跨域应用亦能支持。
5SSO产品研究
5.1CAS
5.1.1简介
CAS（CentralAuthenticationService）是Yale大学发起的一个开源项目。
旨在为Web应用系统提供一种可靠的单点登录方法，CAS在2004年12月正式成为JA-SIG的一个项目。
经历由CAS1到CAS3的发展，CAS已成为非常稳定并广泛应用的开源SSO产品。
5.1.2CAS结构体系
从结构体系看，CAS包含两部分：
ØCASServer
CASServer负责完成对用户的认证工作，CASServer需要独立部署
CASServer会处理用户名/密码等凭证（Credentials）。
CAS均提供一种灵活但同一的接口/实现分离的方式，CAS的认证方式，和CAS协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。
CAS3使用Spring来实现接口和实现的分离，方便用户配置和自行扩展验证接口。
ØCASClient
CASClient负责部署在客户端（只纳入单点登录的Web应用），以Filter方式保护Web应用的受保护资源，过滤从客户端过来的每一个Web请求，如用户未具有访问凭证，而是重定向到CASServer进行认证。
目前，CASClient支持（某些在完善中）非常多的客户端，包括Java、.Net、ISAPI、Php、Perl、uPortal、Acegi、Ruby、VBScript等客户端，几乎可以这样说，CAS协议能够适合任何语言编写的客户端应用。
5.1.3CAS协议
CAS协议分为基础协议和代理协议两种：
Ø基础协议
适用场合：
参与SSO的应用都为Web应用，且各应用之间相互独立，没有复杂的集成关系。
Ø代理协议
适用场合：
参与SSO的应用存在非Web应用（CAS使用Cookie，故非Web应用不宜于直接做CAS的客户应用）
应用之间，存在集成关系。
对于邮政实现SSO，使用简单的基础协议已能满足需要。
对CAS协议，更为细致的介绍可阅：
5.1.4安全性
CAS从v1到v3，都很依赖于SSL，它假定了这样一个事实，用户在一个非常不安全的网络环境中使用SSO。
ØTGC（Ticketgrantingcookie）是CASServer通过SSL方式发送给终端用户，因此，要截取TGC难度非常大，从而确保CAS的安全性。
ØServiceTicket（ST）只能使用一次，无论ServiceTicket验证是否成功，CASServer都会将服务端的缓存中清除该Ticket，从而可以确保一个ServiceTicket被使用两次。
ØServiceTicket在一段时间内失效，CAS提供过期时间的配置。
ØServiceTicket是基于随机数生成的。
5.1.5应用实践
应用SSO，需要有多台机器，多个应用支持测试。
方便起见，修改本地Host文件进行跨域多应用模拟，域名映射如下：
127.0.0.1
127.0.0.1
127.0.0.1
为验证服务器（CAS服务端），和模拟两个跨域应用服务器。
5.1.5.1下载文件版本
CAS当前最新的Release版本：
服务器端：
CASServer3.3.5Final.
客户端（JAVA版）：
cas-client-3.1.10-release
网上对CAS的中文介绍主要集中在2.x版本，CAS由版本2到版本3有较大的变化，引入Spring进行了重构，主体包名也有变化，由之前的edu.yale.its.tp.cas变化为org.jasig.cas。
5.1.5.2Server端部署
解压缩cas-server-3.3.5-release.zip，在\cas-server-3.3.5\modules文件夹下有cas-server-webapp-3.3.5.war文件，为标准的WEB应用程序。
发布之前，将文件重命名为cas.war，采用标准的war包发布方式进行应用发布。
5.1.5.2.1SSL方式
采用SSL方式访问CAS服务器，保证访问的安全性。
使用SSL，需要进行如下步骤：
Ø生成证书
在使用专业的CA证书之前，可使用java自带的keytool工具制作自签名证书。
1、生成服务端密匙
keytool-genkey-aliascasserver-keyalgRSA-keypasschangeit-storepasschangeit-keystoreserver.keystore
2、生成服务端证书
keytool-export-aliascasserver-storepasschangeit-fileserver.cer-keystoreserver.keystore
命令执行后生成一个server.cer的证书文件
3、生成客户端密匙，执行以下命令
keytool-genkey-aliascasclient-keyalgRSA-keypasschangeit-storepasschangeit-keystoreclient.keystore
4、生成客户端证书，执行以下命令
keytool-export-aliascasclient-storepasschangeit-fileclient.cer-keystoreclient.keystore
命令执行后生成一个server.cer的证书文件
5、导入证书文件到cacerts文件中，执行以下命令
keytool-import-trustcacerts-aliasserver-fileserver.cer-keystorecacerts-storepasschangeit
keytool-import-trustcacerts-aliasclient-fileclient.cer-keystorecacerts-storepasschangeit
6、把cacerts文件，拷贝到\jre\lib\security目录下
Ø给应用服务器配置SSL
不同应用服务器SSL配置不同。
以Tomcat为例，打开tomcat\conf\server.xml文件，查找8443，修改如下：
maxThreads="150"minSpareThreads="25"maxSpareThreads="75"
enableLookups="false"disableUploadTimeout="true"
acceptCount="100"scheme="https"secure="true"
clientAuth="false"sslProtocol="TLS"
keystoreFile="E:
/appserver/tomcat5.0.28/server.keystore"
keystorePass="changeit"
truststoreFile="E:
/java/jdk1.5.0_06/jre/lib/security/cacerts"/>
5.1.5.2.2非SSL方式
SSL认证能保证安全性
但SSL需要制作证书、需要应用服务器配置SSL。
另外，一般应用都是http协议，在https和http之间进行跳转，会有安全警告。
如应用系统也采用ssl，由于传输之前信道加密导致性能上会有些问题。
CAS也支持非SSL认证，只需修改\cas\WEB-INF\spring-configuration\ticketGrantingTicketCookieGenerator.xml配置文件：
将p:
cookieSecure="true"改为p:
cookieSecure="false"接口。
这样可以使用普通的http协议访问CASSERVER。
5.1.5.3Client端部署
Ø解压缩cas-client-3.1.10-release.zip，将\cas-client-3.1.10\modules\cas-client-core-3.1.10.jar文件复制至应用的web-inf\lib目录下。
Ø修改WEB-INF/web.xml文件，增加Filter:
serverName
:
8888
CASAuthenticationFilter
org.jasig.cas.client.authentication.AuthenticationFilter
--casserverLOGINURL-->
--:
8443/cas/login-->
casServerLoginUrl
:
8888/cas/login
--CASValidationFILTER-->
CASValidationFilter
org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter
--CASSERVERURL-->
--:
8443/cas-->
casServerUrlPrefix
:
8888/cas
--ifvalidationfalsethrowexception;defaulttrue-->
exceptionOnValidationFailure
false
--cassecurityusernameonrequest.getRemoteUser（）-->
CASHttpServletRequestWrapperFilter
org.jasig.cas.client.util.HttpServletRequestWrapperFilter
--CASSINGLESIGNOUTFILTER-->
CASSingleSignOutFilter
org.jasig.cas.client.session.SingleSignOutFilter
CASSingleSignOutFilter
/*
CASValidationFilter
/*
CASAuthenticationFilter
/*
CASHttpServletRequestWrapperFilter
/index.jsp
--SingleSignOutHttpSessionListenerLISTENER-->
org.jasig.cas.client.session.SingleSignOutHttpSessionListener
主要是应用Server地址和CAS服务器地址的设置。
5.1.5.4认证接口实现
CAS默认提供的认证实现很简单，只需要输入的用户名和密码相同即可。
打开cas\web-inf\deployerConfigContext.xml文件，默认采取SimpleTestUsernamePasswordAuthenticationHandler进行认证。
5.1.5.4.1数据库
Ø从下载包中将cas-server-support-jdbc-3.3.5.jar文件复制与cas\web-inf\lib文件夹下。
该包提供了3个基于JDBC的AuthenticationHandler，分别为BindModeSearchDatabaseAuthenticationHandler,QueryDatabaseAuthenticationHandler,SearchModeSearchDatabaseAuthenticationHandler
我们这里使用的是QueryDatabaseAuthenticationHandler,它是通过配置一个SQL语句查出密码，与所给密码匹配
根据密码加密方式的不同，实现PasswordEncoder接口，来对输入的密码进行加密才能与数据库中的密码比较。
Ø新增com.ist.cas.CASPasswordEncoder.java类，implementsPasswordEncoder接口，数据库密码采取MD5算法加密：
//MD5密码加密
publicStringencode（StringstrSource）{
MD5theMD5=newMD5（）;
StringstrPassMD5=theMD5.getMD5ofStr（strSource）;
returnstrPassMD5;
}
Ø修改cas\web-inf\deployerConfigContext.xml文件：
"/>
升级会员 