CAS技术文档.docx
- 文档编号:17970550
- 上传时间:2023-08-05
- 格式:DOCX
- 页数:27
- 大小:27.20KB
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文件
/ssokeys/cas"keystorepass="changeit"> 参数说明: ? 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配置实例 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
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- CAS 技术 文档