- 浏览: 262832 次
- 性别:
- 来自: 深圳
文章分类
- 全部博客 (88)
- JAVA / base (26)
- JAVA / web (12)
- JAVA / Lib-tools (5)
- SERVER / tomcat (4)
- DB / mysql (4)
- DB / mongodb (2)
- DB / memcached (2)
- DB / redis (2)
- WEB / Front-end (3)
- WEB / security (4)
- WEB / css (2)
- WEB / js (4)
- OS / linux (3)
- IT / Architecture (4)
- IT / other (2)
- Android (9)
- Go (1)
- Other (1)
- OS / Mac (2)
最新评论
-
Zero2Max:
哈哈,马士兵老师也发现了。
java实现接口的bug -
xly1981:
能像CSRF攻击一样带个图就更棒了
XSS跨站攻击 -
xmong:
df274119386 写道在javascript中看到下面的 ...
CSRF攻击与防御策略 -
df274119386:
在javascript中看到下面的语句 e.value = t ...
CSRF攻击与防御策略 -
xmong:
yzxqml 写道xmong 写道yzxqml 写道tomca ...
Tomcat集群
SSO单点登录
目录
1 单点登录 1
1.1 单点登录的背景 1
1.2 什么是单点登录 1
1.3 单点登录的好处 3
1.4 单点登录的解决方案 3
2 CAS 3
2.1 CAS简介 3
2.2 CAS原理与协议 3
2.3 CAS认证依据 4
3 CAS配置 5
3.1 环境准备 5
3.2 CAS-SERVER配置 5
3.2.1 Cas-Server的部署 5
3.2.2 Cas-Server HTTPS取消配置 5
3.2.3 Cas-Server验证方式配置 6
3.2.4 Cas-Server超时配置 7
3.3 CAS-CLIENT配置 8
3.3.1 Cas-Client的部署 8
3.3.2 Cas-Client的配置 8
3.4 HTTPS配置 10
3.4.1 生成server key 10
3.4.2 将证书导入JDK的证书信任库中 10
3.4.3 配置tomcat 11
3.4.4 恢复相应的配置 11
1 单点登录
1.1 单点登录的背景
随着信息化进一步发展和企业的业务运营需要,企业内部的应用系统越来越多。如OA办公自动化系统,HR人力资源管理系统,企业ERP系统,企业BBS系统等,这些系统有着自己独立的用户认证模块和机制,用户不得不记住每一个系统的登录账号和密码,并且在使用不同的系统时,必须重复登录,给用户带来了很大的不便,同时对用户信息没有一个很好的统一管理,使得维护用户信息变的比较困难。针对这种情况,单点登录模型应用而生。
1.2 什么是单点登录
单点登录(Single Sign On),简称为 SSO,是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。
单点登录的机制如下图所示,当用户第一次访问应用系统1的时候,因为还没有登录,会被引导到认证系统中进行登录(1);根据用户提供的登录信息,认证系统进行身份效验,如果通过效验,应该返回给用户一个认证的凭据--ticket(2);用户再访问别的应用的时候(3,5)就会将这个ticket带上,作为自己认证的凭据,应用系统接受到请求之后会把ticket送到认证系统进行效验,检查ticket的合法性(4,6)。如果通过效验,用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
从上面的视图可以看出,要实现SSO,需要以下主要的功能:
• 所有应用系统共享一个身份认证系统。
统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较,对用户进行登录认证;认证成功后,认证系统应该生成统一的认证标志(ticket),返还给用户。另外,认证系统还应该对ticket进行效验,判断其有效性。
• 所有应用系统能够识别和提取ticket信息
要实现SSO的功能,让用户只登录一次,就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取,通过与认证系统的通讯,能自动判断当前用户是否登录过,从而完成单点登录的功能。
上面的功能只是一个非常简单的SSO架构,在现实情况下的SSO有着更加复杂的结构。有两点需要指出的是:
• 单一的用户信息数据库并不是必须的,有许多系统不能将所有的用户信息都集中存储,应该允许用户信息放置在不同的存储中,如下图所示。事实上,只要统一认证系统,统一ticket的产生和效验,无论用户信息存储在什么地方,都能实现单点登录。
• 统一的认证系统并不是说只有单个的认证服务器,如下图所示,整个系统可以存在两个以上的认证服务器,这些服务器甚至可以是不同的产品。认证服务器之间要通过标准的通讯协议,互相交换认证信息,就能完成更高级别的单点登录。如下图,当用户在访问应用系统1时,由第一个认证服务器进行认证后,得到由此服务器产生的ticket。当他访问应用系统4的时候,认证服务器2能够识别此ticket是由第一个服务器产生的,通过认证服务器之间标准的通讯协议(例如SAML)来交换认证信息,仍然能够完成SSO的功能。
1.3 单点登录的好处
从用户的角度来看:能够及时的访问到所需的资源,提高生产效率,避免了记忆多个用户名,密码,增强了用户体验。
从安全的角度来看:单点登录为其他应用系统提供了更强的身份认证机制,从而提高了整体系统的安全性。
从管理的角度来看:单点登录统一了身份认证和机制,减少了系统维护人员的工作。
1.4 单点登录的解决方案
目前有很多单点登录的实现方案,其中最常用的就是单点认证机制。
2 CAS
2.1 CAS简介
CAS 是 Yale 大学发起的一个开源项目,旨在为 Web 应用系统提供一种可靠的单点登录方法,CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。CAS 具有以下特点:
开源的企业级单点登录解决方案。
CAS Server 为需要独立部署的 Web 应用。
CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用),包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
2.2 CAS原理与协议
从结构上看,CAS 包含两个部分: CAS Server 和 CAS Client。CAS Server 需要独立部署,主要负责对用户的认证工作;CAS Client 负责处理对客户端受保护资源的访问请求,需要登录时,重定向到 CAS Server。下图是 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 的交互均采用 SSL 协议,确保,ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程,但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。
2.3 CAS认证依据
TGC:(Ticket granting cookie)允许票据cookie(cookie中包含有TGT)浏览器在登录CAS认证中心成功后,认证中心在该浏览器中写下的一个没有任何人信息的cookie,主要表示该用户已经被认证中心通过,为以后登录应用系统提供依据。
ST:(Service Ticket)服务票据 当用户从浏览器请求使用受保护的资源时,应该用的CAS认证客户端会自动重新定向到认证中心,认证中心根据TGC分发给该请求一个服务票据,然后CAS认证客户端持有该ST去确认并取得该用户的身份。
3 CAS配置
3.1 环境准备
JAVA环境:JDK-1.6,Tomcat-6,MySQL-5.1
CAS:cas-server-3.4.11,cas-client-3.2.1
CAS下载地址: http://www.jasig.org/cas
3.2 Cas-Server配置
3.2.1 Cas-Server的部署
下载cas-server程序,将cas-server-webapp-<版本号>.war 拷贝到 tomcat的 webapps 目录,并更名为 cas_server.war
启动 tomcat,然后访问:https://localhost:8080/cas_server ,如果能出现正常的 CAS 登录页面,则说明 CAS Server 已经部署成功。同时也要修改WEB-INF/ cas.properties中 server.prefix=http://localhost:8080/cas_server
3.2.2 Cas-Server HTTPS取消配置
(1)修改cas server下\WEB-INF\deployerConfigContext.xml文件
增加参数p:requireSecure="false",是否需要安全验证,即true采用HTTPS,false为不采用。
(2)修改cas server下
WEB-INF\springconfiguration\ticketGrantingTicketCookieGenerator.xml文件
参数p:cookieSecure="true",TRUE为采用HTTPS验证,与deployerConfigContext.xml的参数保持一致。
参数p:cookieMaxAge=“-1”,简单说是COOKIE的最大生命周期,-1为无生命周期,即只在当前打开的IE窗口有效,IE关闭或重新打开其它窗口,仍会要求验证。可以根据需要修改为大于0的数字,比如3600等,意思是在3600秒内,打开任意IE窗口,都不需要验证。
(3)修改cas server下\WEB-INF\spring-configuration\warnCookieGenerator.xml文件
两个参数与上面同理。
3.2.3 Cas-Server验证方式配置
cas server下\WEB-INF\deployerConfigContext.xml文件中默认了cas账号验证方式。该认证方式为用户名和密码相同即可通过认证。即默认情况下,登录的时候我们只要输入相同的用户名和密码即可登录成功。
3.2.3.1 配置数据库验证
(1) 加入数据库验证依赖包
将下载的 cas-server-3.4.11-release.zip 包解开后,在 modules 目录下可以找到包 cas-server-support-jdbc-3.4.11.jar,将该包加入到cas server项目的lib依赖库中,该包提供了通过 JDBC 连接数据库进行验证的缺省实现,基于该包的支持,我们只需要做一些配置工作即可实现 JDBC 认证。JDBC 认证方法支持多种数据库,DB2, Oracle, MySql, Microsoft SQL Server 等均可
(2) 配置数据源
cas server下\WEB-INF\deployerConfigContext.xml文件中配置数据源
(3) 注释默认认证方式
(4) 配置SQL方式的验证
(5) 配置指定表和字段的验证方式
(6) 配置自己的加密验证方式
(自定义加密方式 ,此时需增加mypasswordEncoder bean)
此类默认支持MD5 与SHA1两种加密方式,若不满足需求则可自定义加密方式,需实现PasswordEncoder 接口
(7) L
3.2.4 Cas-Server超时配置
• 服务端连接超时配置
修改cas server下\WEB-INF\sping-configuration\applicationContext.xml,
• TGC的存活周期
修改\WEB-INF\spring-configuration\ticketExpirationPolicies.xml文件,通过TimeoutExpirationPolicy来设置CAS TGC存活周期参数,参数默认是120分钟,在合适的范围内设置最小值,太短,会影响SSO体验,太长,会增加安全性风险。
3.3 Cas-Client配置
3.3.1 Cas-Client的部署
将下载的 cas-client-3.2.1-release.zip 包解开后,在 modules 目录下可以找到包 cas-client-core-3.2.1.jar和commons-logging-1.1.jar,将该包加入到cas client项目的lib依赖库中。
3.3.2 Cas-Client的配置
在cas client项目的web.xml加入下面的配置。
3.4 HTTPS配置
3.4.1 生成server key
进入cmd转到E:\下输入
keytool -genkey -alias casserver -keyalg RSA -keypass changeit -storepass changeit -keystore server.keystore -validity 3600
注:参数 -validity 指证书的有效期(天),缺省有效期很短,只有90天。
生成证书时,您的名字与姓氏是什么,必须添域名或cas server机器名,否则SSL将不能取得TGC信息。(证书至关重要,直接影响CAS是否能正常工作)
生成server.keystore文件成功.
3.4.2 将证书导入JDK的证书信任库中
第一步是导出证书,命令如下:
第二步是导入到证书信任库,命令如下:
注:根据不同的JDK版本证书需要导入jdk/jre中。
列出所导入证书
删除存在的证书
3.4.3 配置tomcat
将生成证书复制到tomcat主目录下,修改%TOMCAT_HOME%\conf\server.xml,添加如下配置
keystoreFile为已经生成的服务器证书的地址
keystorePass为自定义的服务器证书的密码
3.4.4 恢复相应的配置
在cas server配置中恢复取消HTTPS的配置。
在cas client配置中修改cas server路径,将http路径修改为https路径。
-----------------------------------------------
参考:
单点登录实现文档
cas配置文档
目录
1 单点登录 1
1.1 单点登录的背景 1
1.2 什么是单点登录 1
1.3 单点登录的好处 3
1.4 单点登录的解决方案 3
2 CAS 3
2.1 CAS简介 3
2.2 CAS原理与协议 3
2.3 CAS认证依据 4
3 CAS配置 5
3.1 环境准备 5
3.2 CAS-SERVER配置 5
3.2.1 Cas-Server的部署 5
3.2.2 Cas-Server HTTPS取消配置 5
3.2.3 Cas-Server验证方式配置 6
3.2.4 Cas-Server超时配置 7
3.3 CAS-CLIENT配置 8
3.3.1 Cas-Client的部署 8
3.3.2 Cas-Client的配置 8
3.4 HTTPS配置 10
3.4.1 生成server key 10
3.4.2 将证书导入JDK的证书信任库中 10
3.4.3 配置tomcat 11
3.4.4 恢复相应的配置 11
1 单点登录
1.1 单点登录的背景
随着信息化进一步发展和企业的业务运营需要,企业内部的应用系统越来越多。如OA办公自动化系统,HR人力资源管理系统,企业ERP系统,企业BBS系统等,这些系统有着自己独立的用户认证模块和机制,用户不得不记住每一个系统的登录账号和密码,并且在使用不同的系统时,必须重复登录,给用户带来了很大的不便,同时对用户信息没有一个很好的统一管理,使得维护用户信息变的比较困难。针对这种情况,单点登录模型应用而生。
1.2 什么是单点登录
单点登录(Single Sign On),简称为 SSO,是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。
单点登录的机制如下图所示,当用户第一次访问应用系统1的时候,因为还没有登录,会被引导到认证系统中进行登录(1);根据用户提供的登录信息,认证系统进行身份效验,如果通过效验,应该返回给用户一个认证的凭据--ticket(2);用户再访问别的应用的时候(3,5)就会将这个ticket带上,作为自己认证的凭据,应用系统接受到请求之后会把ticket送到认证系统进行效验,检查ticket的合法性(4,6)。如果通过效验,用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
从上面的视图可以看出,要实现SSO,需要以下主要的功能:
• 所有应用系统共享一个身份认证系统。
统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较,对用户进行登录认证;认证成功后,认证系统应该生成统一的认证标志(ticket),返还给用户。另外,认证系统还应该对ticket进行效验,判断其有效性。
• 所有应用系统能够识别和提取ticket信息
要实现SSO的功能,让用户只登录一次,就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取,通过与认证系统的通讯,能自动判断当前用户是否登录过,从而完成单点登录的功能。
上面的功能只是一个非常简单的SSO架构,在现实情况下的SSO有着更加复杂的结构。有两点需要指出的是:
• 单一的用户信息数据库并不是必须的,有许多系统不能将所有的用户信息都集中存储,应该允许用户信息放置在不同的存储中,如下图所示。事实上,只要统一认证系统,统一ticket的产生和效验,无论用户信息存储在什么地方,都能实现单点登录。
• 统一的认证系统并不是说只有单个的认证服务器,如下图所示,整个系统可以存在两个以上的认证服务器,这些服务器甚至可以是不同的产品。认证服务器之间要通过标准的通讯协议,互相交换认证信息,就能完成更高级别的单点登录。如下图,当用户在访问应用系统1时,由第一个认证服务器进行认证后,得到由此服务器产生的ticket。当他访问应用系统4的时候,认证服务器2能够识别此ticket是由第一个服务器产生的,通过认证服务器之间标准的通讯协议(例如SAML)来交换认证信息,仍然能够完成SSO的功能。
1.3 单点登录的好处
从用户的角度来看:能够及时的访问到所需的资源,提高生产效率,避免了记忆多个用户名,密码,增强了用户体验。
从安全的角度来看:单点登录为其他应用系统提供了更强的身份认证机制,从而提高了整体系统的安全性。
从管理的角度来看:单点登录统一了身份认证和机制,减少了系统维护人员的工作。
1.4 单点登录的解决方案
目前有很多单点登录的实现方案,其中最常用的就是单点认证机制。
2 CAS
2.1 CAS简介
CAS 是 Yale 大学发起的一个开源项目,旨在为 Web 应用系统提供一种可靠的单点登录方法,CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。CAS 具有以下特点:
开源的企业级单点登录解决方案。
CAS Server 为需要独立部署的 Web 应用。
CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用),包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
2.2 CAS原理与协议
从结构上看,CAS 包含两个部分: CAS Server 和 CAS Client。CAS Server 需要独立部署,主要负责对用户的认证工作;CAS Client 负责处理对客户端受保护资源的访问请求,需要登录时,重定向到 CAS Server。下图是 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 的交互均采用 SSL 协议,确保,ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程,但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。
2.3 CAS认证依据
TGC:(Ticket granting cookie)允许票据cookie(cookie中包含有TGT)浏览器在登录CAS认证中心成功后,认证中心在该浏览器中写下的一个没有任何人信息的cookie,主要表示该用户已经被认证中心通过,为以后登录应用系统提供依据。
ST:(Service Ticket)服务票据 当用户从浏览器请求使用受保护的资源时,应该用的CAS认证客户端会自动重新定向到认证中心,认证中心根据TGC分发给该请求一个服务票据,然后CAS认证客户端持有该ST去确认并取得该用户的身份。
3 CAS配置
3.1 环境准备
JAVA环境:JDK-1.6,Tomcat-6,MySQL-5.1
CAS:cas-server-3.4.11,cas-client-3.2.1
CAS下载地址: http://www.jasig.org/cas
3.2 Cas-Server配置
3.2.1 Cas-Server的部署
下载cas-server程序,将cas-server-webapp-<版本号>.war 拷贝到 tomcat的 webapps 目录,并更名为 cas_server.war
启动 tomcat,然后访问:https://localhost:8080/cas_server ,如果能出现正常的 CAS 登录页面,则说明 CAS Server 已经部署成功。同时也要修改WEB-INF/ cas.properties中 server.prefix=http://localhost:8080/cas_server
3.2.2 Cas-Server HTTPS取消配置
(1)修改cas server下\WEB-INF\deployerConfigContext.xml文件
<bean class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler" p:httpClient-ref="httpClient" p:requireSecure="false"/>
增加参数p:requireSecure="false",是否需要安全验证,即true采用HTTPS,false为不采用。
(2)修改cas server下
WEB-INF\springconfiguration\ticketGrantingTicketCookieGenerator.xml文件
<bean id="ticketGrantingTicketCookieGenerator" class="org.jasig.cas.web.support.CookieRetrievingCookieGenerator" p:cookieSecure="false" p:cookieMaxAge="-1" p:cookieName="CASTGC" p:cookiePath="/cas" /> </beans>
参数p:cookieSecure="true",TRUE为采用HTTPS验证,与deployerConfigContext.xml的参数保持一致。
参数p:cookieMaxAge=“-1”,简单说是COOKIE的最大生命周期,-1为无生命周期,即只在当前打开的IE窗口有效,IE关闭或重新打开其它窗口,仍会要求验证。可以根据需要修改为大于0的数字,比如3600等,意思是在3600秒内,打开任意IE窗口,都不需要验证。
(3)修改cas server下\WEB-INF\spring-configuration\warnCookieGenerator.xml文件
<bean id="warnCookieGenerator" class="org.jasig.cas.web.support.CookieRetrievingCookieGenerator" p:cookieSecure="false" p:cookieMaxAge="-1" p:cookieName="CASPRIVACY" p:cookiePath="/cas" />
两个参数与上面同理。
3.2.3 Cas-Server验证方式配置
cas server下\WEB-INF\deployerConfigContext.xml文件中默认了cas账号验证方式。该认证方式为用户名和密码相同即可通过认证。即默认情况下,登录的时候我们只要输入相同的用户名和密码即可登录成功。
<bean class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" />
3.2.3.1 配置数据库验证
(1) 加入数据库验证依赖包
将下载的 cas-server-3.4.11-release.zip 包解开后,在 modules 目录下可以找到包 cas-server-support-jdbc-3.4.11.jar,将该包加入到cas server项目的lib依赖库中,该包提供了通过 JDBC 连接数据库进行验证的缺省实现,基于该包的支持,我们只需要做一些配置工作即可实现 JDBC 认证。JDBC 认证方法支持多种数据库,DB2, Oracle, MySql, Microsoft SQL Server 等均可
(2) 配置数据源
cas server下\WEB-INF\deployerConfigContext.xml文件中配置数据源
<!-- 数据源 --> <bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close"> <property name="driverClass" value="${jdbc.driverClassName}" /> <property name="jdbcUrl" value="${jdbc.url}" /> <property name="user" value="${jdbc.username}" /> <property name="password" value="${jdbc.password}" /> <property name="maxPoolSize" value="${jdbc.maxPoolSize}" /> <property name="minPoolSize" value="${jdbc.minPoolSize}" /> <property name="initialPoolSize" value="${jdbc.initialPoolSize}" /> <property name="maxIdleTime" value="${jdbc.maxIdleTime}" /> </bean>
(3) 注释默认认证方式
<!-- <bean class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" /> -->
(4) 配置SQL方式的验证
<!-- 用sql形式验证 --> <bean class="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler"> <property name="sql" value="select password from t_user where username=?" /> <property name="dataSource" ref="dataSource" /> </bean>
(5) 配置指定表和字段的验证方式
<bean class="org.jasig.cas.adaptors.jdbc.SearchModeSearchDatabaseAuthenticationHandler" abstract="false" lazy-init="default" autowire="default"> <property name="dataSource" ref="dataSource" /> <property name=“tableUsers” value=“t_user” /> <property name="fieldUser" value="username"/> <property name="fieldPassword" value="password"/> </bean>
(6) 配置自己的加密验证方式
<!-- 在用户验证中加入 --> <bean class="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler"> <property name="sql" value="select password from users where username=?" /> <property name="dataSource" ref="dataSource" /> <property name=“passwordEncoder” ref=“mypasswordEncoder”/> </bean>
(自定义加密方式 ,此时需增加mypasswordEncoder bean)
<bean id="mypasswordEncoder" class="org.jasig.cas.authentication.handler.DefaultPasswordEncoder"> <constructor-arg value="MD5"/> </bean>
此类默认支持MD5 与SHA1两种加密方式,若不满足需求则可自定义加密方式,需实现PasswordEncoder 接口
(7) L
3.2.4 Cas-Server超时配置
• 服务端连接超时配置
修改cas server下\WEB-INF\sping-configuration\applicationContext.xml,
<bean id="httpClient" class="org.jasig.cas.util.HttpClient" p:readTimeout="5000" p:connectionTimeout="5000"/>
• TGC的存活周期
修改\WEB-INF\spring-configuration\ticketExpirationPolicies.xml文件,通过TimeoutExpirationPolicy来设置CAS TGC存活周期参数,参数默认是120分钟,在合适的范围内设置最小值,太短,会影响SSO体验,太长,会增加安全性风险。
<bean id="grantingTicketExpirationPolicy" class="org.jasig.cas.ticket.support.TimeoutExpirationPolicy"> <!-- This argument is the time a ticket can exist before its considered expired. --> <constructor-arg index="0" value="7200000" /> </bean>
3.3 Cas-Client配置
3.3.1 Cas-Client的部署
将下载的 cas-client-3.2.1-release.zip 包解开后,在 modules 目录下可以找到包 cas-client-core-3.2.1.jar和commons-logging-1.1.jar,将该包加入到cas client项目的lib依赖库中。
3.3.2 Cas-Client的配置
在cas client项目的web.xml加入下面的配置。
<!-- 单点退出 可选配--> <filter> <filter-name>CAS Single Sign Out Filter</filter-name> <filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class> </filter> <filter-mapping> <filter-name>CAS Single Sign Out Filter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <listener> <listener-class>org.jasig.cas.client.session.SingleSignOutHttpSessionListener</listener-class> </listener> <!-- 用户单点登录认证,必须配置 --> <filter> <filter-name>CAS Authentication Filter</filter-name> <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class> <init-param> <param-name>casServerLoginUrl</param-name> <param-value>http://localhost:8080/cas_server/login</param-value> </init-param> <init-param> <param-name>serverName</param-name> <param-value>http://localhost:8080</param-value> </init-param> </filter> <!-- ticket认证,必须配置 --> <filter> <filter-name>CAS Validation Filter</filter-name> <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class> <init-param> <param-name>casServerUrlPrefix</param-name> <param-value>http://localhost:8080/cas_server</param-value> </init-param> <init-param> <param-name>serverName</param-name> <param-value>http://localhost:8080</param-value> </init-param> <init-param> <param-name>useSession</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>redirectAfterValidation</param-name> <param-value>true</param-value> </init-param> </filter> <!—request封装请求参数配置 可选配置 --> <filter> <filter-name>CAS HttpServletRequest WrapperFilter</filter-name> <filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class> </filter> <filter-mapping> <filter-name>CAS Authentication Filter</filter-name> <url-pattern>/protected/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>CAS Validation Filter</filter-name> <url-pattern>/protected/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>CAS HttpServletRequest WrapperFilter</filter-name> <url-pattern>/protected/*</url-pattern> </filter-mapping>
3.4 HTTPS配置
3.4.1 生成server key
进入cmd转到E:\下输入
keytool -genkey -alias casserver -keyalg RSA -keypass changeit -storepass changeit -keystore server.keystore -validity 3600
注:参数 -validity 指证书的有效期(天),缺省有效期很短,只有90天。
生成证书时,您的名字与姓氏是什么,必须添域名或cas server机器名,否则SSL将不能取得TGC信息。(证书至关重要,直接影响CAS是否能正常工作)
生成server.keystore文件成功.
3.4.2 将证书导入JDK的证书信任库中
第一步是导出证书,命令如下:
keytool -export -trustcacerts -alias casserver -file server.cer -keystore server.keystore -storepass changeit
第二步是导入到证书信任库,命令如下:
keytool -import -trustcacerts -alias casserver -file server.cer -keystore D:\Java\jre1.6.0_02\lib\security\cacerts -storepass changeit
注:根据不同的JDK版本证书需要导入jdk/jre中。
列出所导入证书
keytool -list -v -keystore D:\Java\jre1.6.0_02\lib\security\cacerts
删除存在的证书
Keytool -delete -trustcacerts -alias casserver -keystore D:\Java\jre1.6.0_02\lib\security\cacerts -storepass changeit
3.4.3 配置tomcat
将生成证书复制到tomcat主目录下,修改%TOMCAT_HOME%\conf\server.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="e:/servercas1.keystore" keystorePass="changeit"/>
keystoreFile为已经生成的服务器证书的地址
keystorePass为自定义的服务器证书的密码
3.4.4 恢复相应的配置
在cas server配置中恢复取消HTTPS的配置。
在cas client配置中修改cas server路径,将http路径修改为https路径。
-----------------------------------------------
参考:
单点登录实现文档
cas配置文档
相关推荐
SSO单点登录技术是现代企业级应用架构中不可或缺的一部分,它通过统一的身份认证服务提升了用户体验,降低了运维复杂度。"Simple-SSO"项目为开发者提供了一个学习和实践SSO的平台,结合Maven的项目管理,使得分布式...
sso单点登录ppt.ppt
SSO(Single Sign-On)单点登录是一种网络访问控制机制...对于理解SSO单点登录解决方案,提升企业内部系统的用户体验和安全管理具有重要价值。通过深入学习这些资料,可以掌握如何设计和实施一个高效、安全的SSO系统。
SSO(Single Sign-On)单点登录...总之,SSO单点登录为用户提供了便捷的访问体验,同时降低了管理多系统登录的复杂性。通过理解其原理和实现方式,我们可以根据具体需求选择合适的技术方案,构建高效且安全的SSO系统。