CAS-认证流程

从结构上看cas包括两个部分，CAS server 和CAS client 需要独立部署，主要负责用户的认证工作，CAS负责处理对客户端受保护资源的访问请求，需要登录时，重新定向到CAS Server

CAS Client 与受保护的客户端应用部署在一起，以Filter方式保护web应用的受保护资源，过滤从客户端过来的每一个web请求，同时CAS client会分析HTTP请求中是否包含请求service Ticket, 如果没有，则说明该用户是没有经过认证的，于是CAS Client会重定向用户请求到CAS server

3) 用户认证过程，如果用户提供了正确的Credentials，CAS Server会产生一个随机的Server Ticket ，然后，缓存该Ticket。并且重定向用户到CAS Client(附带刚才产生的Service Ticket)Service Ticket是不可以伪造的

5) CAS Client 和CAS Server之间完成了一个对用户的身份核实，用Ticket 查找userName，因为Ticket是CAS Server产生的。

总结如下：

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

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

用户认证：用户身份认证

发放票据：sso服务器会产生一个随机的service ticket

验证票据：sso服务器验证票据service ticket 的合法性，验证通过后，允许客户端访问服务

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

用户首次登录时流程

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

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

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

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

5）系统A将受限资源返回给用户

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

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

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

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

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

5）系统B将受限资源返回给客户端

 

 

登录状态判断

用户到认证中心登录后，用户和认证中心之间建立起了回话，我们把这个会话成为全局会话。

当用户后续访问系统应用时，我们不可能每次应用请求都到认证中心去判定是否登录，这样效率非现低下，这样也是单web应用不需要考虑的

可以在系统应用和用户浏览器之间建立局部会话

局部会话保持了客户端与该系统应用的登录状态，局部会话依附于全局会话存在，全局会话消失，局部会话必须消失

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

 

系统登出

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

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

整个登出流程

1）客户端向应用A发出登出logout请求

2）应用A取消本地会话，同时通知认证中心用户已登出

3）应用A返回客户端登出请求

4）认证中心通知所有用户登录访问的应用，用户已登出

 

疑问解答

系统A是如何发现该请求需要登录重定向到认证中心的

用户通过浏览器地址访问系统A，系统A(也可以称为CAS客户端)去Cookie中拿JSESSION，即在Cookie中维护的当前会话session的ID，如果拿到了说明用户已经登录，如果没有拿到，说明用户未登录

系统A重定向到认证中心，发送了什么信息或者地址变成了什么

假如系统A的地址为http://a:8080/，CAS认证中心的服务地址为http://cas.server:8080/，那么重定向前后地址变化为 http://a:8080/------>http://cas.server:8080/?service=http://a:8080/由此可知，重定向到认证中心，认证中心拿到了当前访问客户端的地址

登录成功后，认证中心重定向请求到系统A，认证通过令牌是如何附加发送给系统A的

重定向之后的地址栏变成：http://a:8080/?ticket=ST-XXX-XXXX,票据以ticket为参数名的方式通过地址栏发送给系统A

系统A验证令牌，怎样操作证明用户登录的

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

登录B系统，认证中心是如何判断用户已经登录的

在系统A登录成功后，用户和认证中心之间建立起了全局会话，这个全局会话就是TGT(Ticket Granting Ticket)，TGT位于CAS服务器端，TGT并没有放在sesssion中，也就是说，CAS全局会话的实现并没有直接使用session机制，而是利用cookie自己实现的，这个cookie叫做TGC(ticket granting cookie)，它存在了TGT的id，保存在用户浏览器器。

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

登出的过程，各个系统对当前用户都做了什么

认证中心清除当前用户的全局TGT，同时清掉cookie中的TGT的id:TGC

然后是各个客户端系统，比如系统A，系统B，清除局部会话session，同时清掉cookie中session会话id，jession

 

 

 

系统A登录流程图，添加注释