单点登录CAS技术概述

简述连接地址

http://www.360doc.com/content/15/0204/17/21706453_446251626.shtml

部署应用链接地址

http://www.360doc.com/showweb/0/0/444451531.aspx

1 简介

单点登录（Single Sign On ,简称SSO）是目前比较流行的服务于企业业务整合的解决方案之一，SSO 使得在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

SSO的实现机制不尽相同，大体分为Cookie机制和Session机制两大类。

Session是一种服务器端机制，当客户端访问服务器时，服务器为客户端创建一个惟一的SessionID，以使在整个交互过程中始终保持状态，而交互的信息则可由应用自行指定，因此用Session方式实现SSO，不能在多个浏览器之间实现单点登录，但却可以跨域。

Cookie是一种客户端机制，它存储的内容主要包括：名称、值、过期时间、路径和域，路径与域合在一起就构成了Cookie的作用范围，因此用Cookie方式可实现SSO，但域名必须相同。

目前大部分SSO产品采用的是Cookie机制，最好的开源单点登录产品CAS也是采用Cookie机制。

CAS（Central Authentication Service）是 Yale大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方法。CAS开始于2001年，并在2004年12月正式成为JA-SIG的一个项目。

2 CAS的特性

1) 开源的、多协议的SSO解决方案，CAS Server和CAS Client通信支持多协议，如：CAS、Oauth、OpenID、SAML1.1、SAML2.0D等。

2) 支持多种认证机制：Active Directory、JAAS、JDBC、LDAP、X.509 Certificates等。

3) 安全策略：使用票据（Ticket）来实现支持的认证协议；

4) 支持多种客户端：Java、.Net、PHP、Perl、Apache、 uPortal等。

5) 支持授权：可以决定哪些服务可以请求和验证服务票据（Service Ticket）。

6) 提供高可用性：通过把认证过的状态数据存储在TicketRegistry组件中，这些组件有很多支持分布式环境的实现。

3 CAS原理

3.1 体系结构

CAS包含CAS Server和CAS Client两个部分。

CAS Server负责完成对用户的认证工作，需要独立部署，CAS Server 会处理用户名/ 密码等凭证(Credentials)。

CAS Client负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到CAS Server进行认证。原则上，客户端应用不再接受任何的用户名密码等。CAS Client与受保护的客户端应用部署在一起，以Filter方式保护受保护的资源。

图1 CAS框架图

3.2 CAS 协议

3.2.1 基础协议

CAS 基础协议执行步骤如下：

1) 访问服务：用户发送请求访问应用系统（可称为CAS客户端）提供的受保护的服务资源。

2) 重定向认证：CAS客户端分析HTTP请求中没有Service Ticket（即ST）或SessionID，说明用户还没有进行身份认证。于是，重定向用户请求到CAS服务器进行身份认证，并把用户此次访问CAS客户端的URL作为参数（service）传递给CAS服务器。

3) 用户认证：CAS服务器接收到身份认证请求后转向登录页面，用户提供认证信息后进行身份认证。身份认证成功后，CAS服务器以SSL方式给浏览器返回一个TGC（用户身份信息凭证，用于以后获取ST）。

4) 发放票据：CAS服务器会产生一个随机的ST，然后重定向到CAS客户端。

5) 验证票据：CAS客户端收到ST后，向CAS服务器验证票据ST的合法性，验证通过后，允许用户访问客户端服务。

6) 传输用户信息：CAS服务器验证票据ST通过后，传输用户认证结果信息给客户端。

图2 CAS基础协议流程图

3.2.2 代理协议

CAS基础模式已经能够满足大部分简单的 SSO 应用。现在，我们探讨一种更复杂的情况，即用户访问 helloservice， helloservice又依赖于helloservice2 来获取一些信息，如同：

User -----> helloservice -----> helloservice2。

这种情况下，假设 helloservice2 也是需要对 User 进行身份验证才能访问，那么，为了不影响用户体验（过多的重定向导致 User 的IE 窗口不停地闪动）， CAS 引入了一种 Proxy 认证机制，即 CAS Client 可以代理用户去访问其它 Web 应用。

代理的前提是 CAS Client 要拥有用户的身份信息 ( 类似TGC ) ，而PGT 就是CAS Client 持有的对用户身份信息的一种凭据。凭借 TGC ， User 可以获取访问其它服务的ST，所以，凭借 PGT ，CAS Client可以从CAS Server获取访问代理应用的PT，于是Web 应用可以代理用户去实现后端的认证，而无需前端用户的参与。

如图3所示， CAS Client 在基础协议之上，提供了一个额外的 PGT URL 给 CAS Server。于是，CAS Server 可以通过 PGT URL 提供一个PGT 给 CAS Client 。

图3 CAS Client获取PGT流程图

图4 CAS Client访问应用流程图

4 CAS的安全性

CAS的安全性依赖于SSL，并且其安全性要求远高于普通的应用系统。

4.1 TGC/PGT 安全性

对于一个 CAS 用户来说，最重要是要保护它的 TGC ，如果 TGC 不慎被 CAS Server 以外的实体获得， Hacker 能够找到该 TGC ，然后冒充 CAS 用户访问所有授权资源。

PGT 跟 TGC 的角色是一样的，如果被 Hacker 获得，后果可想而知。

从基础模式可以看出， TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保 CAS 的安全性。另外，TGC也有自己的存活周期。下面是 CAS 的 web.xml 中，通过 grantingTimeout 来设置 CAS TGC 存活周期的参数，参数默认是 120 分钟，在合适的范围内设置最小值，太短，会影响 SSO 体验，太长，会增加安全性风险。

<context-param>

<param-name>edu.yale.its.tp.cas.grantingTimeout</param-name>

<param-value>7200</param-value>

</context-param>

4.2 ST/PT 安全性

ST是通过 HTTP 传送的，所以ST可以被截取到。CAS 协议从几个方面让 ST变得更加安全。

1) Service Ticket 只能使用一次。CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会将服务端的缓存中清除该 Ticket ，从而可以确保一个 Service Ticket 仅被使用一次。

2) ST 在一段时间内失效，默认5分钟。

3) ST是随机产生的。

5 术语解释

CAS系统中设计了5种票据：TGC、ST、PGT、PGTIOU、PT。

Ticket-granting cookie（TGC）：存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，并且只能基于安全通道传输（HTTPS），是CAS Server用来明确用户身份的凭证。