国内更全面
解决程序疑难杂症

CAS 实现单点登录(SSO)基本实现流程(一)

概念:


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

 

CASCentral 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去访问serviceserviceSTCAS验证,验证通过后,允许用户访问资源

 

深入CAS

 

从结构上看,CAS包含两个部分:

 

CAS Server

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

 

CAS Client

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

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

 

CAS最基本的协议过程:


              


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


1,(step 1Web浏览器访问CAS Client,无session并且无票据(ST),定向到CASServerstep 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 客户端应用A的处理

 

第一步:收到ticket后,向cas提交验证ticket

第二步:ticket验证后创建session

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

 

到此为止,CAS会记录用户已在应用A已经登录

 

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


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

 

 

原理:1个cookie+N个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 ,当然这只是一个基础,在理论的基础上帮助大家理解,接下来会实现一个简单实例,让大家通过代码来理解一下这个过程。

 

下篇继续!




企业站定制,我们更专业!

联系我们