cas系列(一)--cas单点登录基本原理

(这段时间打算做单点登录，因此研究了一些cas资料并作为一个系列记录下来，一来可能会帮助一些人，二来对我自己所学知识也是一个巩固。) 

一、为什么要实现单点登录

随着信息化不断发展，企业的信息化过程是一个循序渐进的过程，在企业各个业务网站逐步建设的过程中，根据各种业务信息水平的需要构建了相应的应用系统，由于这些应用系统一般是 在不同的时期开发完成的，各应用系统由于功能侧重、设计方法和开发技术都有所不同，也就形成了各自独立的用户库和用户认证体系。随着新的业务网站不断的增 加，用户在每个应用系统中都有独立的账号，这样就造成在访问不同的应用系统时，需要记录对应的用户名和密码，多个用户名密码极易记混，如果忘记或记错了某 一个业务网站的用户名或密码就无法进行登录，耽误工作，影响工作效率，随着局内信息化进程的推进还会有新的应用系统产生，如果不引入单一用户登录的解决方 案，全公司工作人名特别是承担审批权限的各级领导很难记清各类应用系统的用户名和密码，严重影响由信息化带来快捷性和高效性。此外，多个应用平台就有多个 用户管理，这也为系统管理员维护人员系统带来巨大的工作量，例如，一次变更10个人员，即使只有5个应用系统，也需要重复维护50个人员信息，而企业的每 次人员调整远不至10人，这种几何增长的维护工作量，会浪费大量的精力和时间，减弱了信息化系统带来方便快捷，为此，需建立一套统一的、完善的、科学的单 点登录系统，每个用户只需记录一个用户名密码，登录一个平台后即可实现各应用系统的透明跳转，而且实行统一的用户信息管理系统，系统管理员只需维护一套人 员信息，更改信息通过平台接口同步更新至各个应用系统，实现人员系统单次维护全公司同步变更，大大提高工作效率。

二、认识SSO

（一）单点登录的英文名称为Single Sign-On，简写为SSO，它是一个用户认证的过程，允许用户一次性进行认证之后，就访问系统中不同的应用；而不需要访问每个应用时，都重新输入密码。IBM对SSO有一个形象的解释“单点登录、全网漫游”。
SSO将一个企业内部所有域中的用户登录和用户帐号管理集中到一起，SSO的好处显而易见：
减少用户在不同系统中登录耗费的时间，减少用户登录出错的可能性
实现安全的同时避免了处理和保存多套系统用户的认证信息
减少了系统管理员增加、删除用户和修改用户权限的时间
增加了安全性：系统管理员有了更好的方法管理用户，包括可以通过直接禁止和删除用户来取消该用户对所有系统资源的访问权限

（二） SSO的实现机制不尽相同，大体分为Cookie机制和Session机制两大类。
WebLogic通过Session共享认证信息。Session是一种服务器端机制，当客户端访问服务器时，服务器为客户端创建一个惟一的 SessionID，以使在整个交互过程中始终保持状态，而交互的信息则可由应用自行指定，因此用Session方式实现SSO，不能在多个浏览器之间实 现单点登录，但却可以跨域。
WebSphere通过Cookie记录认证信息。Cookie是一种客户端机制，它存储的内容主要包括: 名字、值、过期时间、路径和域，路径与域合在一起就构成了Cookie的作用范围，因此用Cookie方式可实现SSO，但域名必须相同。

三、认识cas

（一）CAS 单点登录系统最早由耶鲁大学开发。2004年12月，CAS成为JA-SIG中的一个项目。JA-SIG的全称是Java Architectures Special Interest Group，是在高校中推广和探讨基于Java的开源技术的一个组织。CAS的优点很多，例如设计理念先进、体系结构合理、配置简单、客户端支持广泛、技 术成熟等等。

（二）cas主要特性

1、 开源的、多协议的 SSO 解决方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。
2、 支持多种认证机制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等；
3、 安全策略：使用票据（ Ticket ）来实现支持的认证协议；
4、 支持授权：可以决定哪些服务可以请求和验证服务票据（ Service Ticket ）；
5、 提供高可用性：通过把认证过的状态数据存储在 TicketRegistry 组件中，这些组件有很多支持分布式环境的实现，如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等；
6、 支持多种客户端： Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。

四、cas基本原理

（一）结构体系

从结构体系看， CAS 包括两部分： CAS Server 和 CAS Client 。CAS Server 负责完成对用户的认证工作 , 需要独立部署 , CAS Server 会处理用户名 / 密码等凭证 (Credentials) 。CAS Client负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。（原则上，客户端应用不再接受任何的用户名密码等 Credentials ）。CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。

（二）cas原理和协议---基础模式

基础模式 SSO 访问流程主要有以下步骤：
1. 访问服务： SSO 客户端发送请求访问应用系统提供的服务资源。
2. 定向认证： SSO 客户端会重定向用户请求到 SSO 服务器。
3. 用户认证：用户身份认证。
4. 发放票据： SSO 服务器会产生一个随机的 Service Ticket 。
5. 验证票据： SSO 服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问服务。
6. 传输用户信息： SSO 服务器验证票据通过后，传输用户认证结果信息给客户端。
下面是 CAS 最基本的协议过程：

如上图：

1.应用程序一开始，通常跳过原来的登陆界面，而直接转向CAS自带的登录界面。当然也可以在应用程序的主界面上增加一个登录之类的按钮，来完成跳转工作。
2.如果用户喜欢的话，也可以手工直接进入CAS的登录界面，先进行登录，在启动其他的应用程序。不过这种模式主要用于测试环境。
3.CAS的登录界面处理所谓的“主体认证”。它要求用户输入用户名和密码，就像普通的登录界面一样。
4.主体认证时，CAS获取用户名和密码，然后通过某种认证机制进行认证。通常认证机制是LDAP。
5.为了进行以后的单点登录，CAS向浏览器送回一个所谓的“内存cookie”。这种cookie并不是真的保存在内存中，而只是浏览器一关 闭，cookie就自动过期。这个cookie称为“ticket-granting cookie”，用来表明用户已经成功地登录。
6.认证成功后，CAS服务器创建一个很长的、随机生成的字符串，称为“Ticket”。随后，CAS将这个ticket和成功登录的用户，以及服务联系在一起。这个ticket是一次性使用的一种凭证，它只对登录成功的用户及其服务使用一次。使用过以后立刻失效。
7.主体认证完成后，CAS将用户的浏览器重定向，回到原来的应用。CAS客户端，在从应用转向CAS的时候，同时也会记录原始的URL，因此CAS知道谁在调用自己。CAS重定向的时候，将ticket作为一个参数传递回去。
8.例如原始应用的网址是http://www.itil.com/，在这个网址上，一开始有如下语句，转向CAS服务器的单点登录页面https: //secure.oa.com/cas/login?service=http://www.itil.com/auth.aspx。
9.CAS完成主体认证后，会使用下面URL进行重定向http://www.itil.com/authenticate.aspx?ticket= ST-2-7FahVdQ0rYdQxHFBIkKgfYCrcoSHRTsFZ2w-20。
10.收到ticket之后，应用程序需要验证ticket。这是通过将ticket 传递给一个校验URL来实现的。校验URL也是CAS服务器提供的。
11.CAS通过校验路径获得了ticket之后，通过内部的数据库对其进行判断。如果判断是有效性，则返回一个NetID给应用程序。
12.随后CAS将ticket作废，并且在客户端留下一个cookie。
13.以后其他应用程序就使用这个cookie进行认证（当然通过CAS的客户端），而不再需要输入用户名和密码。
采用.NET 来实现CAS原理的SSO系统，在第一个版本的SSO系统基础上罗列一些问题，有的已经是第一个版本的SSO系统中采用的方式。

（三）cas原理和协议---代理模式

该模式形式为用户访问 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原理和协议---辅助说明

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原理和协议---安全性

TGC/PGT 安全性：
对于一个 CAS 用户来说，最重要是要保护它的 TGC ，如果 TGC 不慎被 CAS Server 以外的实体获得， Hacker 能够找到该 TGC ，然后冒充 CAS 用户访问 所有 授权资源。 PGT 的角色跟 TGC 是一样的。
从基础模式可以看出， TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保 CAS 的安全性。
TGT 的存活周期默认为 120 分钟。

ST/PT 安全性：
ST （ Service Ticket ）是通过 Http 传送的，因此网络中的其他人可以 Sniffer 到其他人的 Ticket 。 CAS 通过以下几方面来使 ST 变得更加安全（事实上都是可以配置的）：
1、 ST 只能使用一次
CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会清除服务端缓存中的该 Ticket ，从而可以确保一个 Service Ticket 不被使用两次。
2、 ST 在一段时间内失效
CAS 规定 ST 只能存活一定的时间，然后 CAS Server 会让它失效。默认有效时间为 5 分钟。
3、 ST 是基于随机数生成的
ST 必须足够随机，如果 ST 生成规则被猜出， Hacker 就等于绕过 CAS 认证，直接访问 对应的 服务。

 

转自：http://m.blog.csdn.net/article/details?id=51177500