CAS 实现单点登录（SSO）基本实现流程（一）

概念：

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

CAS（Central Authentication Service），中央认证服务。CAS(Central Authentication
Service)是一款不错的针对 Web应用的单点登录框架。

讲解CAS之前先来学习两个基本术语

术语解释：

Ø Ticket Grangting Ticket(TGT) ：
TGT是CAS为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。TGT封装了Cookie值以及此Cookie值对应的用户信息。用户在CAS认证成功后，CAS生成cookie（叫TGC），写入浏览器，同时生成一个TGT对象，放入自己的缓存，TGT对象的ID就是cookie的值。当HTTP再次请求到来时，如果传过来的有CAS生成的cookie，则CAS以此cookie值为key查询缓存中有无TGT，如果有的话，则说明用户之前登录过，如果没有，则用户需要重新登录。
Ø Ticket-granting
cookie(TGC)：
存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，并且只能基于安全通道传输（Https），是CASServer用来明确用户身份的凭证。
Ø Service ticket(ST) ：服务票据，服务的惟一标识码 , 由 CASServer 发出（ Http 传送），用户访问Service时，service发现用户没有ST，则要求用户去CAS获取ST.用户向CAS发出获取ST的请求，CAS发现用户有TGT，则签发一个ST，返回给用户。用户拿着ST去访问service，service拿ST去CAS验证，验证通过后，允许用户访问资源

深入CAS

从结构上看，CAS包含两个部分：

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

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

CAS最基本的协议过程：

CAS Client 与受保护的客户端应用部署在一起，以Filter方式保护 Web应用的受保护资源，过滤从客户端过来的每一个 Web 请求

1，（step 1）Web浏览器访问CAS
Client，无session并且无票据(ST)，定向到CASServer（step
2），又因为浏览器中并没有cookie，故服务端拿不到TGC，因此需要重新登录

2，（Step 3）是用户认证过程，如果用户提供了正确的CAS
Server 会处理用户名 / 密码等凭证 (Credentials) ，认证成功后，CAS生成cookie（叫TGC），写入浏览器，同时生成一个TGT对象，再根据TGT发放票据ST，并且重定向用户到CAS
Client（附带刚才产生的ServiceTicket）， Service Ticket 是不可以伪造的（step4）
注：ST前半部分为登录url，后半部分为我客户端要访问的页面地址，只有当登录成功才会直接转向客户端访问的页面

3，（Step 5）拿着ST去
CAS Server验证一下，验证成功返回用户信息（step6）
注：收到ST后，为什么还要验证呢？
因为CAS知道这个用户已经登录过了，但是对于这个项目来说，我并不知道这个用户已经登录过了，故需要验证


4，当用户访问另一个应用的服务再次被重定向到 CAS Server 的时候， CAS Server 会主动获到这个 TGC cookie ，然后做下面的事情：
1)如果 User 持有 TGC 且其还没失效，那么就走基础协议图的 Step4 ，达到了 SSO 的效果；
2)如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。

CAS 请求认证时序图如下：

１. CAS服务端登录时处理：

第一步：cas往浏览器增加cookie（TGC）
CAS向浏览器送回一个所谓的“内存cookie”。这种cookie并不是真的保存在内存中，而只是浏览器一关闭，cookie就自动过期。这个cookie称为“ticket-grantingcookie”，用来表明用户已经成功地登录。

这个Cookie是一个加密的Cookie，其中保存了用户登录的信息。用于以后其它应用客户端登录。

第二步：cas同时创建一个ticket(ST)重定向到原来的cas客户端
认证成功后，CAS服务器创建一个很长的、随机生成的字符串，称为“Ticket”。随后，CAS将这个ticket和成功登录的用户，以及服务联系在一起。这个ticket是一次性使用的一种凭证，它只对登录成功的用户及其服务使用一次。使用过以后立刻失效。

２. CAS 客户端应用Ａ的处理

第一步：收到ticket后，向cas提交验证ticket
第二步：ticket验证后创建session
以后登录此应用时，没有ticket，但IE能提供session,从session中取得CASReceipt,并验证如果有效说明已经在此应用认证过，允许访问此应用

到此为止，CAS会记录用户已在应用Ａ已经登录

３. 用户登录到应用Ｂ是如何处理

用户进入应用Ｂ时，首先仍然会重定向到CAS服务器。不过此时CAS服务器不再要求用户输入用户名和密码，而是首先自动寻找Cookie，根据Cookie中保存的信息，进行登录。然后，CAS同样给出新的ticket重定向应用Ｂ给cas验证（流程同应用Ａ验证方式），如果验证成功则应用Ｂ创建session记录CASReceipt信息到session中，以后凭此session登录应用Ｂ。


原理：１个cookie+Ｎ个session

CAS创建cookie在所有应用中登录时cas使用,各应用通过在IE创建各自的session来标识应用是否已经登录。
Cookie:在cas为各应用登录时使用，实现了只须一次录入用户密码
Session:各应用会创建自己的session表示是否登录

具体描述一下客户端消息流程

1.第一次访问http://localhost:8080/a,

CLIENT：没票据且SESSION中没有消息所以跳转至CAS
CAS：拿不到TGC故要求用户登录

2. 认证成功后回跳

CAS：通过TGT生成ST发给客户端，客户端保存TGC，并重定向到http://localhost:8080/a
CLIENT：带有票据(ST)所以不跳转只是后台发给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验证票据，允许用户访问

总结：

以上只是CAS实现的整个流转过程，帮助我们理解CAS是如何做到的SSO
,当然这只是一个基础，在理论的基础上帮助大家理解，接下来会实现一个简单实例，让大家通过代码来理解一下这个过程。

下篇继续！