CAS实现SSO单点登录原理

CAS实现SSO单点登录原理

1.概念

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

 

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

2.术语解释

 > 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验证，验证通过后，允许用户访问资源.

3.原理

  原理：１个cookie+Ｎ个session

    CAS创建cookie在所有应用中登录时cas使用,各应用通过在浏览器创建各自的session来标识应用是否已经登录。

    Cookie:在cas为各应用登录时使用，实现了只须一次录入用户密码

    Session:各应用会创建自己的session表示是否登录

 安全性：

    用户只须在cas录入用户名和密码，之后通过ticket绑定用户，在cas客户端与cas校验是通过ticket，并不会在网上传输密码，所以可以保证安全性，密码不被窃取

4.深入剖析CAS

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

 1）CAS Server

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

 

 2）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 ，然后做下面的事情：

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

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

CAS 请求认证时序图如下：

 

1）CAS服务端登录时处理：

第一步：cas往浏览器增加cookie（TGC） 

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

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

第二步：cas同时创建一个ticket(ST)重定向到原来的cas客户端

认证成功后，CAS服务器创建一个很长的、随机生成的字符串，称为“Ticket”。随后，CAS将这个ticket和成功登录的用户，以及服务联系在一起。这个ticket是一次性使用的一种凭证，它只对登录成功的用户及其服务使用一次。使用过以后立刻失效。

 

2）CAS 客户端应用Ａ的处理

第一步：收到ticket后，向cas提交验证ticket

第二步：ticket验证后创建session

以后登录此应用时，没有ticket，但IE能提供session,从session中取得CASReceipt,并验证如果有效说明已经在此应用认证过，允许访问此应用。

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

3）用户登录到应用Ｂ是如何处理

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