CAS技术文档.docx
《CAS技术文档.docx》由会员分享，可在线阅读，更多相关《CAS技术文档.docx（27页珍藏版）》请在冰点文库上搜索。
CAS技术文档
CentralAuthenticationService（CAS）
1企业单点登录
2CAS系统集成与部署
2.1CAS服务器安装部署
2.1.1创建https协议证书
使用JDK自带的工具keytool生成证书。
keytool-genkey-aliascas-keyalgRSA-keystored:
/ssokeys/cas
密码：
changeit
域名：
导出证书：
keytool-export-filed:
/ssokeys/cas.crt-aliascas-keystored:
/ssokeys/cas
客户端的JVM导入证书
keytool-import-keystorecas
2.1.2配置WEB服务器SSL证书
2.1.2.1Tomcat6
打开tomcat目录的conf/server.xml文件
参数说明：
?
keystoreFile：
在第一步创建的key存放位置
?
keystorePass：
创建证书时的密码
2.1.2.2Weblogic10
2.1.3配置cas程序包
CAS服务器是一个JavaEE工程，需要部署到web服务器中，这里选择Tomcat6作为cas.war程序包的部署容器。
将cas.war包复制到Tomcat的webapps目录下。
此时CAS服务器没有做任何修改，完全采用默认的配置参数，主要是作为测试使用。
其中用户身份验证器验证用户登录名和密码是否一致，如果是一样的则身份验证成功，这只是测试验证，在真正生产部署环境可以使用database，LDAP等方式。
票据注册器采用基于的内存注册器，并采用定时器校验票据的生命周期。
2.2CAS客户端与业务系统集成（Java）
将CAS客户端程序包（cas-client.jar），添加到业务系统的classpath中。
CAS客户端提供了多个Filter过滤器拦截用户请求，判断当前登录状态，重定向到CAS服务器，进行用户身份认证，验证用户TGT。
2.2.1过滤器
拦截用户请求，试图重定向用户请求到CAS服务器进行身份验证，除非用户已经带有TGT表示用户已经验证。
配置参数：
casServerLoginUrl：
CAS服务器提供的用户登录URL路径。
serverName：
。
服务的名称，必须按照这个格式：
{protocol}:
{hostName}:
{port}
service：
/cas-test
精确的业务应用服务URL地址。
其中参数serverName和service两个必须配置其中的一个参数。
不能两个都不配置。
Cas10TicketValidator票据验证器过滤器
配置参数：
casServerPrefix：
renew：
true/false
serverName：
。
服务的名称，必须按照这个格式：
{protocol}:
{hostName}:
{port}
service：
/cas-test
精确的业务应用服务URL地址。
其中参数serverName和service两个必须配置其中的一个参数。
不能两个都不配置。
将用户登录信息放到线程本地中，使其他资源可以方法获得用户登录信息
2.2.2配置实例
authenticationFilter
casServerLoginUrl
serverName
ticketValidationFilter
casServerUrlPrefix
serverName
assertionThreadLocalFilter
authenticationFilter
/*
ticketValidationFilter
/*
assertionThreadLocalFilter
/*
3架构（Architecture）
3.1系统组件
CAS系统由CAS服务器和CAS客户端两个物理系统组成。
这两个物理系统之间使用多种CAS支持的协议进行通信。
3.1.1CAS服务器
CAS服务器是一个JavaEE工程项目，构建于Spring开源框架之上，它最主要的职责是验证用户身份，另一个主要的任务是通过发布和校验ST票据授权用户访问那些CAS嵌入式业务应用。
当CAS服务器成功验证用户登录请求时就会为用户发布一个ticket-grantingticket（TGT）票据，该票据会以cookie的方式保存在用户客户端浏览器中，此时就创建了一个SSO会话。
当用户携带TGT票据通过浏览器访问CAS客户端嵌入式业务系统时CAS服务器会为这个业务系统发布一个serviceticket（ST）票据。
在CAS服务器与CAS客户端后台通信中ST票据会被频繁的验证。
3.1.2CAS客户端
CAS客户端有两个主要的意思。
代表一个CAS客户端嵌入式业务系统，在后台通过特殊的协议与CAS服务器进行通信。
另一个意思代表一个程序包可以集成到一些软件平台或者应用软件中，通过一些通信协议（CAS,SAML,OAuth）与CAS服务器进行通信。
CAS客户端支持以下软件开发平台：
Platforms:
ApachehttpdServer（mod_auth_casmodule）
Java（JavaCASClient）
.NET（.NETCASClient）
PHP（phpCAS）
Perl（PerlCAS）
Python（pycas）
Ruby（rubycas-client）
Applications:
OutlookWebApplication（ClearPass+.NETCASClient）
AtlassianConfluence
AtlassianJIRA
Drupal
Liferay
uPortal
3.2协议
CAS客户端与CAS服务器端连接支持多种通信协议。
所有的这些通信协议都是相似的工作原理。
当然一些通信协议也具有特殊的功能特性，例如：
CAS协议支持代理（proxy）认证，SAML协议支持单点登出。
支持的协议：
CAS（versions1,2,and3）
SAML1.1
OpenID
OAuth（1.0,2.0）
3.3软件组件
CAS服务器包括三层子系统：
Web（SpringMVC/SpringWebflow）
Ticketing
Authentication
几乎所有的部署注意事项和组件配置都包含在这三个子系统中。
Web层是外部系统与CAS服务器通信的端点入口。
Web层委托票据子系统为CAS客户端访问生成票据。
当成功认证用户身份时会发布一个ticket-grantingticket（TGT）票据，这时一个SSO会话就创建成功。
在用户身份验证过程中会频繁的委托认证子系统，验证用户提交的身份数据有效性。
4CAS协议
CAS协议是专为CAS开发的一种简单而强大的基于票据的协议。
关于CAS协议详细说明可以参考。
CAS协议中包括一个或多个CAS客户端和一个CAS服务器。
CAS服务器负责用户验证，授权访问业务应用。
CAS客户端保护CAS客户端嵌入式业务系统，从CAS服务器获得用户信息。
关键概念：
TGT（TicketGrantingTicket）：
保存在CASTGCcookie中，代表一个用户SSO会话。
ST（ServiceTicket）：
通过URL参数传输，代表CAS服务器发布给一个用户访问一个CAS客户端嵌入式业务系统。
4.1版本
当前最新CAS协议版本是3.0，CASServer4.0实现。
主要是在CAS协议2.0版本基础上进行了增强。
4.2Web流程图
4.2代理web流程图
5认证管理器（AuthenticationManager）
AuthenticationManager
AuthenticationHandler
PrincipalResolver
ArgumentExtractors
6身份验证（authentication）
作为一个单点登录解决方案，CAS没有特别偏向哪一种后台用户认证系统。
CAS提供了很多即开即用的验证方式，包括LDAP,database,X.509Certificates,andJAAS。
6.1通用认证处理器
简单的用户认证处理器
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
文件系统用户认证提供器
?
?
?
p:
fileName="file:
/opt/cas/file_of_passwords.txt"?
/>
密码文件例子：
scott:
:
password
bob:
:
password2
6.2JDBC认证处理器
6.2.1数据源
所有的JDBC认证处理器都需要一个数据源DataSource，以下是一个数据源配置实例：
class=
p:
driverClass="${database.driverClass}"
p:
jdbcUrl="${database.url}"
p:
user="${database.user}"
p:
password="${database.password}"
p:
initialPoolSize=
p:
minPoolSize=
p:
maxPoolSize=
p:
maxIdleTimeExcessConnections=
p:
checkoutTimeout=
p:
acquireIncrement=
p:
acquireRetryAttempts=
p:
acquireRetryDelay=
p:
idleConnectionTestPeriod=
p:
preferredTestQuery=/>
#==Basicdatabaseconnectionpoolconfiguration==
database.driverClass=
database.url=jdbc:
postgresqlcas?
ssl=true
database.user=somebody
database.password=meaningless
=6
=18
#Maximumamountoftimetowaitinmsforaconnectiontobecome
#availablewhenthepoolisexhausted
=10000
#Amountoftimeinsecondsafterwhichidleconnections
#inexcessofminimumsizearepruned.
=120
#Numberofconnectionstoobtainonpoolexhaustioncondition.
#Themaximumpoolsizeisalwaysrespectedwhenacquiring
#newconnections.
=6
#==Connectiontestingsettings==
#Periodinsatwhichahealthquerywillbeissuedonidle
#connectionstodetermineconnectionliveliness.
=30
#Queryexecutedperiodicallytotesthealth
=select1
#==Databaserecoverysettings==
#Numberoftimestoretryacquiringa_new_connection
#whenanerrorisencounteredduringacquisition.
=5
#Amountoftimeinmstowaitbetweensuccessiveaquireretryattempts.
=2000
6.2.2QueryDatabaseAuthenticationHandler
class=
c:
encodingAlgorithm="MD5"
p:
characterEncoding="UTF-8"/>
class=
p:
dataSource-ref="dataSource"
p:
passwordEncoder-ref="passwordEncoder"
p:
sql="selectpasswordfromuserswhereusername=?
andactive=1"/>
6.2.3SearchModeSearchDatabaseAuthenticationHandler
class=
c:
encodingAlgorithm="SHA1"
p:
characterEncoding="UTF-8"/>
class=
p:
dataSource-ref="dataSource"
p:
passwordEncoder-ref="passwordEncoder"
p:
tableUsers="users"
p:
fieldUser="username"
p:
fieldPassword="password"/>
6.2.4BindModeSearchDatabaseAuthenticationHandler
class=
p:
dataSource-ref="dataSource"/>
6.3X.509证书认证处理器
6.4LDAP认证处理器
7配置票据组件
配置中票据包括两个核心组件：
TicketRegistry：
提供一种票据持久化方式。
ExpirationPolicy：
提供一种票据过期策略。
7.1票据注册器（TicketRegistry）
在开发环境和生产环境一般需要不同的票据注册器组件。
在HA部署环境中推荐使用基于缓存的组件。
默认实现是基于内存的票据注册器，适应简单的部署环境。
7.1.1Default（In-Memory）TicketRegistry
DefaultTicketRegistry使用ConcurrentHashMap保存和检索票据。
这个组件不支持票据持久化，重启服务后以后的票据都不存在了。
initialCapacity-ConcurrentHashMapinitialcapacity.
loadFactor-ConcurrentHashMaploadfactor.formoreinformation.
concurrencyLevel-AllowstuningtheConcurrentHashMapforconcurrentwritesupport.
class=""
c:
initialCapacity="10000"
c:
loadFactor="1"
c:
concurrencyLevel="20"/>
7.1.2Cache-BasedTicketRegistries
在高可用部署环境中可以使用基于缓存的票据注册器，其提供高性能的票据存储和检解决方案，CAS支持以下缓存技术，Ehcache和Memecahe。
Ehcache
EhCacheTicketRegistry存储票据到ehcache实例中。
以下提供了两种配置：
内存缓存溢出磁盘的简单实例，适用于简单场景。
分布式缓存基于RMI复制，适用于HA部署环境。
简单内存缓存
在Spring的配置文件ticketRegistry.xml中
class=""
p:
serviceTicketsCache-ref="serviceTicketsCache"
p:
ticketGrantingTicketsCache-ref="ticketGrantingTicketsCache"/>
class=""
p:
cacheManager-ref="cacheManager"
p:
diskExpiryThreadIntervalSeconds="0"
p:
diskPersistent="false"
p:
eternal="false"
p:
maxElementsInMemory="10000"
p:
maxElementsOnDisk="20000"
p:
memoryStoreEvictionPolicy="LRU"
p:
overflowToDisk="true"/>
class=""
parent="abstractTicketCache"
p:
cacheName="cas_st"
p:
timeToIdle="0"
p:
timeToLive="300"/>
class=""
p:
cacheName="cas_tgt"
p:
timeToIdle="0"
p:
timeToLive="7201"/>
class=
p:
configLocation="classpath:
ehcache-failsafe.xml"
p:
shared="false"
p:
cacheManagerName="ticketRegistryCacheManager"/>
Ehcache配置文件ehcache-failsafe.xml
xmlns:
xsi=
xsi:
noNamespaceSchemaLocation=>
分布式缓存
在HA部署环境中推荐使用分布式缓存，其为票据存储子系统提供了故障容错机制。
注册器使用不同的缓存实例维护两种票据TGT和ST。
TicketGrantingTickets（TGT）需要维护相当长的一段时间，使用异步复制。
ServiceTickets（ST）生命周期短，需要在集群中的各节点保持一致。
RMIReplication
Ehcache在多节点缓存集群之间支持RMI复制。
Spring配置文件ticketRegistry.xml
class=""
p:
serviceTicketsCache-ref="serviceTicketsCache"
p:
ticketGrantingTicketsCache-ref="ticketGrantingTicketsCache"/>
class=""
p:
cacheManager-ref="cacheManager"
p:
diskExpiryThreadIntervalSeconds="0"
p:
diskPersistent="false"
p:
eternal="false"
p:
maxElementsInMemory="10000"
p:
maxElementsOnDisk="20000"
p:
memoryStoreEvictionPolicy="LRU"
p:
overflowToDisk="true"
p:
bootstrapCacheLoader-ref="ticketCacheBootstrapCacheLoader"/>
--MUSTusesynchronousreplforserviceticketsforcorrectbehavior.-->
class=""
parent="abstractTicketCache"
p:
cacheName="cas_st"
p:
timeToIdle="0"
p:
timeToLive="300"
p:
cacheEventListeners-ref="ticketRMISynchronousCa
升级会员 