CAS实现SSO单点登录原理

一、不落俗套的开始

1、背景介绍

单点登录：Single Sign On,简称SSO，SSO使得在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

CAS框架：CAS（Central Authentication Service）是实现SSO单点登录的框架。

2、盗一张学习CAS绝大多都看过的图以及执行部分分析

注：已分不清原创，此处就不给出地址了。

从结构上看，CAS包含两个部分：CAS Server 和CAS Client需要独立部署，主要负责对用户的认证工作；CAS
Client负责处理对客户端受保护资源的访问请求，需要登录时，重定向到CAS Server.图1是CAS最基本的协议过程：

CAS Client 与受保护的客户端应用部署在一起，以Filter方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个 Web
请求，同时， CAS Client会分析HTTP 请求中是否包请求 Service Ticket( 上图中的 Ticket)
，如果没有，则说明该用户是没有经过认证的，于是，CAS Client会重定向用户请求到CAS Server（ Step 2 ）。 Step
3是用户认证过程，如果用户提供了正确的Credentials， CAS Server 会产生一个随机的 Service Ticket
，然后，缓存该 Ticket ，并且重定向用户到CAS Client（附带刚才产生的Service Ticket）， Service
Ticket 是不可以伪造的，最后， Step 5 和 Step6是 CAS Client 和 CAS
Server之间完成了一个对用户的身份核实，用Ticket查到 Username ，因为 Ticket是 CAS Server
产生的，因此，所以 CAS Server 的判断是毋庸置疑的。

该协议完成了一个很简单的任务，所有与CAS的交互均采用SSL协议，确保ST和TGC的安全性。协议工作过程会有2此重定向过程，但是CAS
Client与CAS Server之间进行ticket验证的过程对于用户是透明的。

总结一下，如下：

访问服务： SSO 客户端发送请求访问应用系统提供的服务资源。

定向认证： SSO 客户端会重定向用户请求到 SSO 服务器。

用户认证：用户身份认证。

发放票据： SSO 服务器会产生一个随机的 Service Ticket 。

验证票据： SSO 服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问服务。

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

二、在云里雾里进一步搜索、探究

先给出此部分内容出处：《SSO CAS单点系列》之 实现一个SSO认证服务器是这样的，以下标红部分为自己的疑问。

1、登录信息传递

用户首次登录时流程如下：

1)、用户浏览器访问系统A需登录受限资源，此时进行登录检查，发现未登录，然后进行获取票据操作，发现没有票据。

2)、系统A发现该请求需要登录，将请求重定向到认证中心，获取全局票据操作，没有，进行登录。

3)、认证中心呈现登录页面，用户登录，登录成功后，认证中心重定向请求到系统A，并附上认证通过令牌，此时认证中心同时生成了全局票据。

4)、此时再次进行登录检查，发现未登录，然后再次获取票据操作，此时可以获得票据(令牌)，系统A与认证中心通信，验证令牌有效,证明用户已登录。

5)、系统A将受限资源返给用户。

已登录用户首次访问应用群中系统B时：

1)、浏览器访问另一应用B需登录受限资源，此时进行登录检查，发现未登录，然后进行获取票据操作，发现没有票据。

2)、系统B发现该请求需要登录，将请求重定向到认证中心，获取全局票据操作，获取全局票据，可以获得，认证中心发现已经登录。

3)、认证中心发放临时票据(令牌)，并携带该令牌重定向到系统B。

4)、此时再次进行登录检查，发现未登录，然后再次获取票据操作，此时可以获得票据(令牌)，系统B与认证中心通信，验证令牌有效,证明用户已登录。

5)、系统B将受限资源返回给客户端。

2、登录状态判断

用户到认证中心登录后，用户和认证中心之间建立起了会话，我们把这个会话称为全局会话。当用户后续访问系统应用时，我们不可能每次应用请求都到认证中心去判定是否登录，这样效率非常低下，这也是单Web应用不需要考虑的。

我们可以在系统应用和用户浏览器之间建立起局部会话，局部会话保持了客户端与该系统应用的登录状态，局部会话依附于全局会话存在，全局会话消失，局部会话必须消失。

用户访问应用时，首先判断局部会话是否存在，如存在，即认为是登录状态，无需再到认证中心去判断。如不存在，就重定向到认证中心判断全局会话是否存在，如存在，按1提到的方式通知该应用，该应用与客户端就建立起它们之间局部会话，下次请求该应用，就不去认证中心验证了。

3、登出

用户在一个系统登出了，访问其它子系统，也应该是登出状态。要想做到这一点，应用除结束本地局部会话外，还应该通知认证中心该用户登出。

认证中心接到登出通知，即可结束全局会话，同时需要通知所有已建立局部会话的子系统，将它们的局部会话销毁。这样，用户访问其它应用时，都显示已登出状态。

整个登出流程如下：

1)、客户端向应用A发送登出Logout请求。
2)、应用A取消本地会话，同时通知认证中心，用户已登出。
3)、应用A返回客户端登出请求。
4)、认证中心通知所有用户登录访问的应用，用户已登出。

三、拨开云雾见青天

1、对上面所有标红疑问一一解释

1)、问：系统A是如何发现该请求需要登录重定向到认证中心的？
答：用户通过浏览器地址栏访问系统A，系统A(也可以称为CAS客户端)去Cookie中拿JSESSION，即在Cookie中维护的当前回话session的id，如果拿到了，说明用户已经登录，如果未拿到，说明用户未登录。

2)、问：系统A重定向到认证中心，发送了什么信息或者地址变成了什么？
答：假如系统A的地址为http://a:8080/，CAS认证中心的服务地址为http://cas.server:8080/，那么重点向前后地址变化为：http://a:8080/————>ttp://cas.server:8080/?service=http://a:8080/，由此可知，重点向到认证中心，认证中心拿到了当前访问客户端的地址。

3)、问：登录成功后，认证中心重定向请求到系统A，认证通过令牌是如何附加发送给系统A的？
答：重定向之后的地址栏变成：http://a:8080/?ticket=ST-XXXX-XXX，将票据以ticket为参数名的方式通过地址栏发送给系统A

4)、问：系统A验证令牌，怎样操作证明用户登录的？
答：系统A通过地址栏获取ticket的参数值ST票据，然后从后台将ST发送给CAS server认证中心验证，验证ST有效后，CAS server返回当前用户登录的相关信息，系统A接收到返回的用户信息，并为该用户创建session会话，会话id由cookie维护，来证明其已登录。

5)、问：登录B系统，认证中心是如何判断用户已经登录的？
答：在系统A登录成功后，用户和认证中心之间建立起了全局会话，这个全局会话就是TGT(Ticket Granting Ticket)，TGT位于CAS服务器端，TGT并没有放在Session中，也就是说，CAS全局会话的实现并没有直接使用Session机制，而是利用了Cookie自己实现的，这个Cookie叫做TGC(Ticket Granting Cookie)，它存放了TGT的id,保存在用户浏览器上。
相关内容分析可以查看：《SSO CAS单点系列》之 实操！轻松玩转SSO CAS就这么简单(相识篇)

用户发送登录系统B的请求，首先会去Cookie中拿JSESSION，因为系统B并未登录过，session会话还未创建，JSESSION的值是拿不到的，然后将请求重定向到CAS认证中心，CAS认证中心先去用户浏览器中拿TGC的值，也就是全局会话id，如果存在则代表用户在认证中心已经登录，附带上认证令牌重定向到系统B。

上面登录状态判断也是这个逻辑。

6)、问：登出的过程，各个系统对当前用户都做了什么？
答：认证中心清除当前用户的全局会话TGT，同时清掉cookie中TGT的id：TGC；
然后是各个客户端系统，比如系统A、系统B，清除局部会话session，同时清掉cookie中session会话id：jsession

2、对系统A登录流程图添加注释，查看

不管了，反正我看懂了。

ps：看到这里的福利，cas系列介绍文章分享：CAS介绍资源页面

http://blog.csdn.net/javaloveiphone/article/details/52439613

1.CAS简介

1.1.What is CAS？

CAS（Central Authentication Service） 是Yale大学发起的一个企业级的、开源的项目，旨在为Web应用系统提供一种可靠的单点登录解决方法（属于Web SSO）。

CAS开始于2001年， 并在2004年12月正式成为JA-SIG的一个项目。

1.2.主要特性

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等。

2.SSO单点登录原理

本文内容主要针对Web SSO。

2.1.什么是SSO

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

2.2.SSO原理

2.2.1.SSO体系中的角色

一般SSO体系主要角色有三种：

1、User（多个）

2、Web应用（多个）

3、SSO认证中心（1个）

2.2.2.SSO实现模式的原则

SSO实现模式一般包括以下三个原则：

1、所有的认证登录都在SSO认证中心进行；

2、SSO认证中心通过一些方法来告诉Web应用当前访问用户究竟是不是已通过认证的用户；

3、SSO认证中心和所有的Web应用建立一种信任关系，也就是说web应用必须信任认证中心。（单点信任）

2.2.3.SSO主要实现方式

SSO的主要实现方式有：

1、共享cookies

基于共享同域的cookie是Web刚开始阶段时使用的一种方式，它利用浏览同域名之间自动传递cookies机制，实现两个域名之间系统令牌传递问题；另外，关于跨域问题，虽然cookies本身不跨域，但可以利用它实现跨域的SSO。如：代理、暴露SSO令牌值等。

缺点：不灵活而且有不少安全隐患，已经被抛弃。

2、Broker-based(基于经纪人)

这种技术的特点就是，有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子身份存取。中央数据库的使用减少了管理的代价，并为认证提供一个公共和独立的"第三方"。例如Kerberos、Sesame、IBM KryptoKnight（凭证库思想)等。Kerberos是由麻省理工大学发明的安全认证服务，已经被UNIX和Windows作为默认的安全认证服务集成进操作系统。

3、Agent-based（基于代理人）

在这种解决方案中，有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如，它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理人被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个"翻译"。例如SSH等。

4、Token-based

例如SecureID,WebID，现在被广泛使用的口令认证，比如FTP、邮件服务器的登录认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用。

5、基于网关

6、基于SAML

SAML(Security Assertion Markup Language，安全断言标记语言）的出现大大简化了SSO，并被OASIS批准为SSO的执行标准。开源组织OpenSAML实现了SAML规范。

3.CAS的基本原理

3.1.结构体系

从结构体系看，CAS包括两部分：CAS Server和CAS Client。

3.1.1.CAS Server

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

3.1.2.CAS Client

负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到CAS Server进行认证。（原则上，客户端应用不再接受任何的用户名密码等Credentials）。

CAS Client与受保护的客户端应用部署在一起，以Filter方式保护受保护的资源。

3.2.CAS原理和协议

3.2.1.基础模式

基础模式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随机产生一个相当长度、唯一、不可伪造的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请求认证时序图如下：

3.2.1.CAS如何实现SSO

当用户访问另一个应用的服务再次被重定向到CAS Server的时候，CAS Server会主动获到这个TGC cookie，然后做下面的事情：

1)如果User持有TGC且其还没失效，那么就走基础协议图的Step4，达到了SSO的效果；

2)如果TGC失效，那么用户还是要重新认证(走基础协议图的Step3)。

3.2.2.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。

3.2.3.辅助说明

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的交互而已。

3.3.术语解释

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 ) ----------密钥发放中心；

4.CAS安全性

CAS的安全性仅仅依赖于SSL。使用的是secure cookie。

4.1.TGC/PGT安全性

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

从基础模式可以看出，TGC是CAS Server通过SSL方式发送给终端用户，因此，要截取TGC难度非常大，从而确保CAS的安全性。

TGT的存活周期默认为120分钟。

4.2.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认证，直接访问对应的服务。

5.参考资料

1、https://wiki.jasig.org/display/CASUM/Introduction

2、http://www.jasig.org/cas/protocol/

3、http://www.ibm.com/developerworks/cn/opensource/os-cn-cas/index.html

4、http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html

5、http://baike.baidu.com/view/190743.htm

http://www.coin163.com/java/cas/cas.html