[转]统一身份认证(CAS)简单说明与设计方案

Posted Crysaty

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[转]统一身份认证(CAS)简单说明与设计方案相关的知识,希望对你有一定的参考价值。

 

统一身份认证(CAS)简单说明与设计方案(转)

1. 单点登录概述

所谓单点登录(SSO),只当企业用户同时访问多个不同(类型的)应用时,他们只需要提供自身的用户凭证信息(比如用户名/密码)一次,仅仅一次。SSO解决方案(比如,CAS)负责统一认证用户,如果需要,SSO也可以完成用户的授权处理。可以看出,当企业用户在不同的应用间切换时,他们不用再重复地输入自身的用户凭证了。在实施SSO后,所用的认证操作都将交给SSO认证中心。现有的SSO解决方案非常多,比如微软的MSN Passport便是典型的SSO解决方案,各Java EE容器都提供了自身的专有SSO能力。

2. CAS的总体架构

1. CAS简介

CAS(中央认证服务)是建立在非常开放的协议之上的企业级SSO解决方案。诞生于2001年,在2002年发布了CAS2.0协议,这一新的协议提供了Proxy(代理)能力,此时的CAS2.0支持多层SSO能力。到2005年,CAS成为了JA-SIG旗下的重要子项目。由于CAS2.0版本的可扩展能力不是非常完美,而且他的架构设计也不是很卓越,为了使得CAS能够适用于更多场合,JA-SIG打算开发出同时遵循CAS1.0和CAS2.0协议的CAS3.X版本。

现在的CAS3全面拥抱Spring技术,比如Spring DI容器和AOP技术、Spring Web MVC、Spring Web Flow、Spring Ldap Template等。

通常,CAS3由两部分内容构成:CAS3服务器和CAS客户端。由于CAS2.0协议借助于XML数据结构与客户进行交互,因此开发者可以使用各种语言编写的CAS3客户与服务器进行通信。CAS3服务器采用纯Java开发而成,它要求目标运行环境实现了Servlet2.4+规范、提供Java SE 1.4+支持。如果宿主CAS3服务器的目标Java EE容器仅仅实现了Servlet2.3-规范,则在对CAS3服务器进行少量的改造后,CAS3也能运行其中。

运行时,CAS3服务器仅仅是一个简单的Web应用,使用者只需要将cas.war直接丢到目标Java EE容器后,即完成了CAS3的部署。

2. CAS词汇概念

TGC(ticket-granting cookie)--------- 受权的票据证明 KDC( Key Distribution Center ) ---------- 密钥发放中心

Service ticket(ST) --------- 服务票据, 由 KDC 的 TGS 发放。 任何一台 Workstation 都需要拥有一张有效的 Service Ticket 才能访问域内部的应用 (Applications) 。 如果能正确接收 Service Ticket ,说明在 CASClient-CASServer 之间的信任关系已经被正确建立起来,通常为一张数字加密的证书 Ticket Granting tieckt(TGT) --------- 票据授权票据,由 KDC 的 AS 发放。即获取这样一张票据后,以后申请各种其他服务票据 (ST) 便不必再向 KDC 提交身份认证信息 ( 准确术语是 Credentials) 。

authentication service (AS) --------- 认证用服务,索取 Crendential ,发放 TGT ticket-granting service (TGS) --------- 票据授权服务,索取 TGT ,发放 ST

3. CAS工作原理

CAS的单点登录的认证过程,所用应用服务器受到应用请求后,检查ST和TGT,如果没有或不对,转到CAS认证服务器登录页面,通过安全认证后得到ST和TGT,再重新定向到相关应用服务器,在回话生命周期之内如果再定向到别的应用,将出示ST和TGT进行认证,注意,取得TGT的过程是通过SSL安全协议的。

如果通俗形象地说就是:相当于用户要去游乐场,首先要在门口检查用户的身份 ( 即 CHECK 用户的 ID 和 PASS), 如果用户通过验证,游乐场的门卫 (AS) 即提供给用户一张门卡 (TGT)。

这张卡片的用处就是告诉游乐场的各个场所,用户是通过正门进来,而不是后门偷爬进来的,并且也是获取进入场所一把钥匙。

现在用户有张卡,但是这对用户来不重要,因为用户来游乐场不是为了拿这张卡的而是为了游览游乐项目,这时用户摩天楼,并想游玩。

这时摩天轮的服务员 (client) 拦下用户,向用户要求摩天轮的 (ST) 票据,用户说用户只有一个门卡 (TGT), 那用户只要把 TGT 放在一旁的票据授权机 (TGS) 上刷一下。

票据授权机 (TGS) 就根据用户现在所在的摩天轮,给用户一张摩天轮的票据 (ST), 这样用户有了摩天轮的票据,现在用户可以畅通无阻的进入摩天轮里游玩了。

当然如果用户玩完摩天轮后,想去游乐园的咖啡厅休息下,那用户一样只要带着那张门卡 (TGT). 到相应的咖啡厅的票据授权机 (TGS) 刷一下,得到咖啡厅的票据 (ST) 就可以进入咖啡厅

当用户离开游乐场后,想用这张 TGT 去刷打的回家的费用,对不起,用户的 TGT 已经过期了,在用户离开游乐场那刻开始,用户的 TGT 就已经销毁了 。

3. CAS的实现原理

由于CAS是基于Cookie的服务,所以它使用了Spring CookieGenerator来生成相应Cookie,下面的代码段摘自与CAS服务器的WEB-INF/中的cas-server.xml配置文件。

 

class=\\ork.web.util.CookieGenerator\\

一旦用户登录到CAS服务器后,可以借助于URL为/cas/logout的地址退出,并且这种logout结果将导致浏览器中已存储的Cookie被销毁掉,即销毁CAS与当前用户间已建立的信任关系(Web SSO会话)。

1. AuthenticationHandler认证处理器

浏览项目的web.xml,可以发现如下内容:

contextConfigLocation

/WEB-INF/applicationContext.xml,

/WEB-INF/deployerConfigContext-acegi.xml

org.jasig.cas.web.init.SafeContextLoaderListener

SafeContextLoaderListener实现了SafeContextListener,它借助于ContextLoader -Listener装载Spring DI容器。这样做的原因是因为Spring在通过

ContextLoaderLitener启动时可能出现异常,造成整个CAS不能正常启动,经过SafeContextLoaderListener,则在异常发生时,CAS服务器也可以启动。

在deployerConfigContext.xml中,可以看到只定义了一个Bean:

class=\\

SimpleTestUsernamePasswordAuthenticationHandler的作用是如果用户名与密码输入一样,则通过系统认证。这个是开发过程中常用的一个handler,但是在开发完毕后应该除去。

AuthenticationManagerImpl负责认证用户,比如一个admin/admin用户是否合法就是它来验证的。AuthenticationManagerImpl对象会借助于他引用的credentialsToPr -incipalResolvers和authenticationHandlers集合完成用户的认证工作。Authentication -Handlers负责完成用户认证,而

credentialsToPrincipalResolvers负责构建认证结果。其中,并不是authenticationHandlers的全部集合都参与到用户认证中,一旦某个AuthenticationHandler成功完成用户的认证,则认证进程就到此为止,进而转到credenti -alsToPrincipalResolvers来构建认证结果。credentialsToPrincipalResolvers的过程也类似于此。

2. CAS的时序图

 

以上是关于[转]统一身份认证(CAS)简单说明与设计方案的主要内容,如果未能解决你的问题,请参考以下文章

CAS统一身份认证:集成MySQL用户验证

SSO统一身份认证——CAS Server6.3.x设定退出方式(十二)

SSO统一身份认证——CAS Server6.3.x中gradlew的使用

简单 SSO - 使用自定义身份验证 - CAS 或一些 Oauth 或 openid 服务器?

简单 SSO - 使用自定义身份验证 - CAS 或一些 Oauth 或 openid 服务器?

统一身份管理中的权限管理设计