简单的 SSO 的体系中,会有下面三种角色:前端
1 , User (多个)web
2 , Web 应用(多个)数据库
3 , SSO 认证中心( 1 个)后端
虽然 SSO 实现模式千奇百怪,但万变不离其宗:跨域
1 Web 应用不处理 User 的登陆,不然就是多点登录了,全部的登陆都在 SSO 认证中心进行。浏览器
2 SSO 认证中心经过一些方法来告诉 Web 应用当前访问用户到底是不是张三 / 李四。缓存
3 SSO 认证中心和全部的 Web 应用创建一种信任关系, SSO 认证中心对用户身份正确性的判断会经过某种方法告之 Web 应用,并且判断结果必须被 Web 应用信任。安全
CAS ( Central Authentication Service ) 是 Yale 大学发起的一个企业级的、开源的项目,旨在为 Web 应用系统提供一种可靠的单点登陆解决方法(属于 Web SSO )。服务器
CAS 开始于 2001 年, 并在 2004 年 12 月正式成为 JA-SIG 的一个项目。cookie
一、 开源的、多协议的 SSO 解决方案; Protocols : Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。
二、 支持多种认证机制: Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等;
三、 安全策略:使用票据( Ticket )来实现支持的认证协议;
四、 支持受权:能够决定哪些服务能够请求和验证服务票据( Service Ticket );
五、 提 供高可用性:经过把认证过的状态数据存储在 TicketRegistry 组件中,这些组件有不少支持分布式环境的实现, 如: BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等;
六、 支持多种客户端: Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。
本文内容主要针对 Web SSO 。
单点登陆( Single Sign-On , 简称 SSO )是目前比较流行的服务于企业业务整合的解决方案之一, SSO 使得在多个应用系统中,用户只须要 登陆一次 就能够访问全部相互信任的应用系统。
通常 SSO 体系主要角色有三种:
一、 User (多个)
二、 Web 应用(多个)
三、 SSO 认证中心( 1 个 )
SSO 实现模式通常包括如下三个原则:
一、 全部的认证登陆都在 SSO 认证中心进行;
二、 SSO 认证中心经过一些方法来告诉 Web 应用当前访问用户到底是不是已经过认证的用户;
三、 SSO 认证中心和全部的 Web 应用创建一种信任关系,也就是说 web 应用必须信任认证中心。(单点信任)
SSO 的主要实现方式有:
一、 共享 cookies
基 于共享同域的 cookie 是 Web 刚开始阶段时使用的一种方式,它利用浏览同域名之间自动传递 cookies 机制,实现两个域名之间系统令牌 传递问题;另外,关于跨域问题,虽然 cookies自己不跨域,但能够利用它实现跨域的 SSO 。如:代理、暴露 SSO 令牌值等。
缺点:不灵活并且有很多安全隐患,已经被抛弃。
二、 Broker-based( 基于经纪人 )
这 种技术的特色就是,有一个集中的认证和用户账号管理的服务器。经纪人给被用于进一步请求的电子身份存取。中央数据库的使用减小了管理的代价,并为认证提供 一个公共和独立的 "第三方 " 。例如 Kerberos 、 Sesame 、 IBM KryptoKnight (凭证库思想 ) 等。 Kerberos是由麻省理工大学发明的安全认证服务,已经被 UNIX 和 Windows 做为 默认的安全认证服务集成进操做系统。
三、 Agent-based (基于代理人)
在 这种解决方案中,有一个自动地为不一样的应用程序认证用户身份的代理程序。这个代理程序须要设计有不一样的功能。好比,它可使用口令表或加密密钥来自动地将 认证的负担从用户移开。代理人被放在服务器上面,在服务器的认证系统和客户端认证方法之间充当一个 " 翻译 "。例如 SSH 等。
四、 Token-based
例如 SecureID,WebID ,如今被普遍使用的口令认证,好比 FTP 、邮件服务器的登陆认证,这是一种简单易用的方式,实现一个口令在多种应用当中使用。
五、 基于网关
六、 基于 SAML
SAML(Security Assertion Markup Language ,安全断言标记语言)的出现大大简化了 SSO ,并被 OASIS 批准为 SSO 的执行标准 。开源组织 OpenSAML 实现了 SAML 规范。
从结构体系看, CAS 包括两部分: CAS Server 和 CAS Client 。
CAS Server 负责完成对用户的认证工做 , 须要独立部署 , CAS Server 会处理用户名 / 密码等凭证(Credentials) 。
负责处理对客户端受保护资源的访问请求,须要对请求方进行身份认证时,重定向到 CAS Server 进行认证。(原则上,客户端应用再也不接受任何的用户名密码等 Credentials )。
CAS Client 与受保护的客户端应用部署在一块儿,以 Filter 方式保护受保护的资源。
基础模式 SSO 访问流程主要有如下步骤:
1. 访问服务: SSO 客户端发送请求访问应用系统提供的服务资源。
2. 定向认证: SSO 客户端会重定向用户请求到 SSO 服务器。
3. 用户认证:用户身份认证。
4. 发放票据: SSO 服务器会产生一个随机的 Service Ticket 。
5. 验证票据: SSO 服务器验证票据 Service Ticket 的合法性,验证经过后,容许客户端访问服务。
6. 传输用户信息: SSO 服务器验证票据经过后,传输用户认证结果信息给客户端。
下面是 CAS 最基本的协议过程:
基础协议图
如 上图: CAS Client 与受保护的客户端应用部署在一块儿,以 Filter 方式保护 Web 应用的受保护资源,过滤从客户端过来的每个 Web 请求,同 时, CAS Client 会分析 HTTP 请求中是否包含请求 Service Ticket( ST 上图中的 Ticket) ,若是没有,则说明该用户是没有通过认证的;因而 CAS Client 会重定向用户请求到 CAS Server ( Step 2 ),并传递 Service (要访问的目的资源地址)。 Step 3 是用户认证过程,若是用户提供了正确的 Credentials , CAS Server 随机产生一个至关长度、惟1、不可伪造的 Service Ticket ,并缓存以待未来验证,而且重定向用户到 Service 所在地址(附带刚才产生的 Service Ticket ) , 并为客户端浏览器设置一个 Ticket Granted Cookie ( TGC ) ; CAS Client 在拿到 Service 和新产生的 Ticket 事后,在 Step 5 和 Step6 中与 CAS Server 进行身份核实,以确保 Service Ticket 的合法性。
在该协议中,全部与 CAS Server 的交互均采用 SSL 协议,以确保 ST 和 TGC 的安全性。协议工做过程当中会有 2 次重定向 的过程。可是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的(使用 HttpsURLConnection )。
CAS 请求认证时序图以下:
当用户访问另外一个应用的服务再次被重定向到 CAS Server 的时候, CAS Server 会主动获到这个 TGC cookie ,而后作下面的事情:
1) 若是 User 持有 TGC 且其还没失效,那么就走基础协议图的 Step4 ,达到了 SSO 的效果;
2) 若是 TGC 失效,那么用户仍是要从新认证 ( 走基础协议图的 Step3) 。
该模式形式为用户访问 App1 , App1 又依赖于 App2 来获取一些信息,如: User -->App1 -->App2。
这 种状况下,假设 App2 也是须要对 User 进行身份验证才能访问,那么,为了避免影响用户体验(过多的重定向致使 User 的 IE 窗口不停地 闪动 ) , CAS 引入了一种 Proxy 认证机制,即 CAS Client 能够代理用户去访问其它 Web 应用。
代 理的前提是须要 CAS Client 拥有用户的身份信息 ( 相似凭据 ) 。以前咱们提到的 TGC 是用户持有对本身身份信息的一种凭据,这里的 PGT 就是 CAS Client 端持有的对用户身份信息的一种凭据。凭借TGC , User 能够免去输入密码以获取访问其它服务的 Service Ticket ,因此,这里凭借 PGT , Web应用能够代理用户去实现后端的认证,而 无需前端用户的参与 。
下面为代理应用( helloService )获取 PGT 的过程: (注: PGTURL 用于表示一个 Proxy 服务,是一个回调连接; PGT 至关于代理证; PGTIOU 为取代理证的钥匙,用来与 PGT 作关联关系;)
如上面的 CAS Proxy 图所示, CAS Client 在基础协议之上,在验证 ST 时提供了一个额外的PGT URL( 并且是 SSL 的入口 ) 给 CAS Server ,使得 CAS Server 能够经过 PGT URL 提供一个 PGT 给 CAS Client 。
CAS Client 拿到了 PGT(PGTIOU-85 … ..ti2td) ,就能够经过 PGT 向后端 Web 应用进行认证。
下面是代理认证和提供服务的过程:
如 上图所示, Proxy 认证与普通的认证其实差异不大, Step1 , 2 与基础模式的 Step1,2 几乎同样,惟一不一样的 是, Proxy 模式用的是 PGT 而不是 TGC ,是 Proxy Ticket ( PT )而不是 Service Ticket 。
CAS 的 SSO 实现方式可简化理解为: 1 个 Cookie 和 N 个 Session 。 CAS Server 建立 cookie,在全部应用认证时使用,各应用经过建立各自的 Session 来标识用户是否已登陆。
用 户在一个应用验证经过后,之后用户在同一浏览器里访问此应用时,客户端应用中的过滤器会在 session 里读取到用户信息,因此就不会去 CAS Server 认证。若是在此浏览器里访问别的 web 应用时,客户端应用中的过滤器在 session 里读取不到用户信息,就会去 CAS Server 的 login 接口认证,但这时CAS Server 会读取到浏览器传来的 cookie ( TGC ),因此 CAS Server 不会要求用户去登陆页面登陆,只是会根据 service 参数生成一个 Ticket ,而后再和 web 应用作一个验 证 ticket 的交互而已。
CAS 系统中设计了 5 中票据: TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。
Ø Ticket-granting cookie(TGC) :存放用户身份认证凭证的 cookie ,在浏览器和 CAS Server 间通信时使用,而且只能基于安全通道传输( Https ),是 CAS Server 用来明确用户身份的凭证;
Ø Service ticket(ST) :服务票据,服务的唯一标识码 , 由 CAS Server 发出( Http 传送),经过客户端浏览器到达业务服务器端;一个特定的服务只能有一个唯一的 ST ;
Ø Proxy-Granting ticket ( PGT ):由 CAS Server 颁发给拥有 ST 凭证的服务, PGT 绑定一个用户的特定服务,使其拥有向 CAS Server 申请,得到 PT 的能力;
Ø Proxy-Granting Ticket I Owe You ( PGTIOU ) : 做用是将经过凭证校验时的应答信息由 CAS Server 返回给 CAS Client ,同时,与该 PGTIOU 对应的 PGT 将经过回调连接传给 Web 应用。 Web 应用负责维护 PGTIOU 与 PGT 之 间映射关系的内容表;
Ø Proxy Ticket (PT) :是应用程序代理用户身份对目标程序进行访问的凭证;
其它说明以下:
Ø Ticket Granting ticket(TGT) :票据受权票据,由 KDC 的 AS 发放。即获取这样一张票据后,之后申请各类其余服务票据 (ST) 便没必要再向 KDC 提交身份认证信息 (Credentials) ;
Ø Authentication service(AS) --------- 认证用服务,索取 Credentials ,发放 TGT ;
Ø Ticket-granting service (TGS) --------- 票据受权服务,索取 TGT ,发放 ST ;
Ø KDC( Key Distribution Center ) ---------- 密钥发放中心;
第一步:
cas往浏览器增长cookie(TGC)
CAS向浏览器送回一个所谓的“内存cookie”。这种cookie并非真的保存在内存中,而只是浏览器一关闭,cookie就自动过时。这个cookie称为“ticket-granting cookie”,用来代表用户已经成功地登陆。
这个Cookie是一个加密的Cookie,其中保存了用户登陆的信息。用于之后其它应用客户端登陆。
第二步:
cas同时建立一个ticket重定向到原来的cas客户端
认证成功后,CAS服务器建立一个很长的、随机生成的字符串,称为“Ticket”。随后,CAS将这个ticket和成功登陆的用户,以及服务联系在一块儿。这个ticket是一次性使用的一种凭证,它只对登陆成功的用户及其服务使用一次。使用过之后马上失效。
第一步:
收到ticket后,向cas提交验证ticket
Cas客户端收到ticket以后,应用程序须要验证ticket。这是经过将ticket 传递给一个校验URL来实现的。校验URL也是CAS服务器提供的。CAS经过校验路径得到了ticket以后,经过内部的数据库对其进行判断。若是判断是有效性,则返回一个NetID给应用程序。随后CAS将ticket做废,而且在客户端留下一个cookie。(谁来建立cookie?),
第二步:
ticket验证后建立session之后登陆此应用时,没有ticket,但IE能提供session,从session中取得CASReceipt,并验证若是有效说明已经在此应用认证过,容许访问此应用,到此为止,CAS会记录用户已在应用A已经登陆
用户进入应用B时,首先仍然会重定向到CAS服务器。不过此时CAS服务器再也不要求用户输 入用户名和密码,而是首先自动寻找Cookie,根据Cookie中保存的信息,进行登陆。而后,CAS一样给出新的ticket重定向应用B给cas验证(流程同应用A验证方式),若是验证成功则应用B建立session记录CASReceipt信息到session中,之后凭此session登陆应用B。
到此为止,CAS会记录用户已在应用A和应用B进行登陆,可是当用户在应用B退出cas登陆时,要通知应用A进行退出,如何通知应用A呢?
CAS server接受请求后,会检测用户的TCG Cookie,把对应的session清除,同时会找到全部经过该TGC sso登陆的应用服务器URL提交请求,全部收到请求的应用服务器application会解析这个参数,取得sessionId,根据这个Id取得session后,把session删除。
这样就实现单点登出的功能。
CAS 的安全性仅仅依赖于 SSL 。使用的是 secure cookie 。
对于一个 CAS 用户来讲,最重要是要保护它的 TGC ,若是 TGC 不慎被 CAS Server 之外的实体得到, Hacker 可以找到该 TGC ,而后冒充 CAS 用户访问 全部 受权资源。 PGT 的角色跟 TGC 是同样的。
从基础模式能够看出, TGC 是 CAS Server 经过 SSL 方式发送给终端用户,所以,要截取 TGC 难度很是大,从而确保 CAS 的安全性。
TGT 的存活周期默认为 120 分钟。
ST ( Service Ticket )是经过 Http 传送的,所以网络中的其余人能够 Sniffer 到其余人的 Ticket 。 CAS 经过如下几方面来使 ST 变得更加安全(事实上都是能够配置的):
一、 ST 只能使用一次
CAS 协议规定,不管 Service Ticket 验证是否成功, CAS Server 都会清除服务端缓存中的该Ticket ,从而能够确保一个 Service Ticket 不被使用两次。
二、 ST 在一段时间内失效
CAS 规定 ST 只能存活必定的时间,而后 CAS Server 会让它失效。默认有效时间为 5 分钟。
三、 ST 是基于随机数生成的
ST 必须足够随机,若是 ST 生成规则被猜出, Hacker 就等于绕过 CAS 认证,直接访问 对应的服务。
1. 第一次访问 http://localhost:8080/A
CLIENT:没票据且SESSION中没有消息因此跳转至CAS
CAS:拿不到TGC故要求用户登陆
2. 认证成功后回跳
CAS:经过TGT生成ST发给客户端,客户端保存TGC,并重定向到http://localhost:8080/A
CLIENT:带有票据因此不跳转只是后台发给CAS验证票据(浏览器中没法看到这一过程)
3. 第一次访问 http://localhost:8080/B
CLIENT:没票据且SESSION中没有消息因此跳转至CAS
CAS:从客户端取出TGC,若是TGC有效则给用户ST并后台验证ST,从而SSO。【若是失效重登陆或注销时,怎么通知其它系统更新SESSION信息呢??
TicketGrantingTicketImpl类grantServiceTicket方法里this.services.put(id,service);可见CAS端已经记录了当前登陆的子系统】
4. 再次访问 http://localhost:8080/A
CLIENT:没票据可是SESSION中有消息故不跳转也不用发CAS验证票据,容许用户访问