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登陆流程图，添加注释