2024年5月10日发(作者:)

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

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

1. 单点登录概述

所谓单点登录(SSO),只当企业用户同时访问多个不同(类型的)应用时,他们只须要供应自身的用户凭证信息(比如用户名/密码)一次,仅仅一次。SSO解决方案(比如,CAS)负责

统一认证用户,假如须要,SSO也可以完成用户的授权处理。可以看出,当企业用户在不同的应用间切换时,他们不用再重复地输入自身的用户凭证了。在实施SSO后,所用的认证操作

都将交给SSO认证中心。现有的SSO解决方案特殊多,比如微软的MSN Passport便是典型的SSO解决方案,各Java EE容器都供应了自身的专有SSO实力。

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

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

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版本。

3. CAS的实现原理

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

class="Generator">

现在的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也能运行其中。

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

(Web SSO会话)。

运行时,CAS3服务器仅仅是一个简洁的Web应用,运用者只须要将干脆丢到目标Java EE容器后,即完成了CAS3的部署。

1. AuthenticationHandler认证处理器

阅读项目的,可以发觉如下内容:

contextConfigLocation

/WEB-INF/,

/WEB-INF/

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平安协议的。

SafeContextLoaderListener实现了SafeContextListener,它借助于ContextLoader -Listener装载Spring DI容器。这样做的缘由是因为Spring在通过ContextLoaderLitener启动时可能出

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

假如通俗形象地说就是:相当于用户要去游乐场,首先要在门口检查用户的身份 ( 即 CHECK 用户的 ID 和 PASS), 假如用户通过验证,游乐场的门卫 (AS) 即供应应用户一张门卡 (TGT)。 在中,可以看到只定义了一个Bean:

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

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

class="ticationManagerImpl">

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

1 / 2

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

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

authenticationHandlers集合完成用户的认证工作。Authentication -Handlers负责完成用户认证,而credentialsToPrincipalResolvers负责构建认证结果。其中,并不是authenticationHandlers

的全部集合都参和到用户认证中,一旦某个AuthenticationHandler成功完成用户的认证,则认证进程就到此为止,进而转到credenti -alsToPrincipalResolvers来构建认证结果。

credentialsToPrincipalResolvers的过程也类似于此。

2. CAS的时序图

来自:

2 / 2