详细探究 CAS的执行流程

什么是CAS:  CAS是一个开源的单点登录解决方案      

CAS 包含两个部分： CAS Server 和 CAS Client。

​        CAS Server 为需要独立部署的 Web 应用。类似于solr,不用我们写代码但是需要改配置文件

​        CAS Client 支持多种语言在我们这里CAS Client就是 购物车系统 ,用户系统,前台系统

三种不同的执行情况:        1.第一次访问资源

​                           2.第二次访问资源

​                           3.第一次访问互相信任的资源

相关概念:        TGT：CAS Ticket Granted Ticket（俗称大令牌，或者说票根，他可以签发ST）存在cas-server端

​                 TGC：CAS Ticket Granted Cookie（cookie中的value），存在Cookie中，根据他可以找到TGT。

​                 ST： Service Ticket （小令牌），是TGT生成的，默认是用一次就生效了。

​        Cookie中的CASTGC：向cookie中添加该值的目的是当下次访问cas.pinyougou.com时，浏览器将Cookie中的TGC携带到cas-server，cas-server根据这个TGC，查找与之对应的TGT。从而判断用户是否登录过了，是否需要展示登录页面。TGT与TGC的关系就像SESSION与Cookie中SESSIONID的关系。

CAS的原理 (执行流程):

• 访问服务：客户端发送请求第一次访问目标资源(比如说直接访问我们品优购的user.pinyougou.com)
  
  
  • 经过他的第一个过滤器（cas提供，在web.xml中配置）AuthenticationFilter。
    ​      过滤器全称：org.jasig.cas.client.authentication.AuthenticationFilter
    ​      主要作用：判断是否登录，如果没有登录则重定向到认证中心。
  • 目标资源发现用户没有登录，则返回浏览器重定向地址()。(重定向地址就是cas服务端)
  • 浏览器接收到重定向的状态码(302)之后发起重定向，请求cas.pinyougou.com并且把目标资源的地址拼接在重定向的地址后   ?service=http://目标资源地址
    
    
• 定向认证：客户端会重定向用户请求到 SSO 服务器。
  
  
  • 认证中心cas.pinyougou.com接收到登录请求，返回登陆页面。
    
    
  
  

• 用户在cas.pinyougou.com的login页面输入用户名密码，提交。
• 用户认证：用户身份认证。
  
  
  • 服务器接收到用户名密码，则验证是否有效，验证逻辑可以使用cas-server提供现成的，也可以自己实现。
    
    
• 发放票据：服务器会产生一个随机的 Service Ticket。
  
  
  • cas-server认证通过后，会返回给浏览器302，重定向的地址就是之前地址service参数对应的值。后边并通过get的方式挟带了一个ticket令牌，这个ticket就是ST。
  • 同时会在Cookie中设置一个CASTGC，该cookie是网站cas.pinyougou.com的cookie，只有访问cas.pinyougou.com才会携带这个cookie过去。
  • 这
    
    
• 验证票据：服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问服务。
  
  
  • 浏览器从cas.pinyougou.com哪里拿到ticket之后，就根据指示重定向到目标资源，请求的url就是上面返回的url(带有ts的url)。
  • 目标资源在过滤器中会取到ticket的值，然后通过http方式调用cas.pinyougou.com(cas.pinyougou.com就是cas-server认证中心)验证该ticket是否是有效的。
  • cas.pinyougou.com接收到ticket之后，验证，验证通过返回结果告诉目标资源该ticket有效。
    
    
• 传输用户信息：服务器验证票据通过后，传输用户认证结果信息给客户端。
  
  
  • 目标资源接收到cas-server的返回，知道了用户合法，展示相关资源到用户浏览器上。
    
    
• 至此第一次访问的整个流程结束
• 第二次访问同一个目标资源(这次不经过cas-server)
  
  
  • 用户发起请求，访问目标资源 会经过过滤器，因为第一次访问成功后会在session中记录用户信息，因此这里直接就通过了，不用验证了。
  • 用户通过权限验证，浏览器返回正常资源。
    
    
• 访问其他互相信任的网站
  
  
  • 用户在用户中心正常上网(pinyougou-user-web) 突然想访问购物车(pinyougou-cart-web)
  • cart.pinyougou.com接收到请求，发现第一次访问，于是给他一个重定向的地址，让他去找认证中心。(同样通过?service=cart.pinyougou.com 带上参数)
  • 重定向到cas-server 因为之前访问过一次了，因此这次会携带上次返回的Cookie：TGC到认证中心。
  • 认证中心收到请求，发现TGC对应了一个TGT，于是用TGT签发一个ST，并且返回给浏览器，让他重定向到cart.pinyougou.com(地址通过service参数获得)
  • 目标资源cart.pinyougou.com获取ticket去认证中心(cas-server)验证是否有效。
  • 认证成功 返回资源并且在cart.pinyougou.com的session中设置登录状态，下次就直接登录。不必经过cas-server认证中心.
    
    
  
  

可以发现请求的时候是携带Cookie：CASTGC的，响应的就是一个地址加上TGT签发的ST也就是ticket。

然后重新重定向到目标资源这时在经过cas-server验证TS验证通过返回资源并把用户信息保持到session中

以上是CAS在不同情况下的执行流程

                详细探究 CAS的执行流程

什么是CAS:  CAS是一个开源的单点登录解决方案      

CAS 包含两个部分： CAS Server 和 CAS Client。

​        CAS Server 为需要独立部署的 Web 应用。类似于solr,不用我们写代码但是需要改配置文件

​        CAS Client 支持多种语言在我们这里CAS Client就是 购物车系统 ,用户系统,前台系统

三种不同的执行情况:        1.第一次访问资源

​                           2.第二次访问资源

​                           3.第一次访问互相信任的资源

相关概念:        TGT：CAS Ticket Granted Ticket（俗称大令牌，或者说票根，他可以签发ST）存在cas-server端

​                 TGC：CAS Ticket Granted Cookie（cookie中的value），存在Cookie中，根据他可以找到TGT。

​                 ST： Service Ticket （小令牌），是TGT生成的，默认是用一次就生效了。

​        Cookie中的CASTGC：向cookie中添加该值的目的是当下次访问cas.pinyougou.com时，浏览器将Cookie中的TGC携带到cas-server，cas-server根据这个TGC，查找与之对应的TGT。从而判断用户是否登录过了，是否需要展示登录页面。TGT与TGC的关系就像SESSION与Cookie中SESSIONID的关系。

CAS的原理 (执行流程):

• 访问服务：客户端发送请求第一次访问目标资源(比如说直接访问我们品优购的user.pinyougou.com)
  
  
  • 经过他的第一个过滤器（cas提供，在web.xml中配置）AuthenticationFilter。
    ​      过滤器全称：org.jasig.cas.client.authentication.AuthenticationFilter
    ​      主要作用：判断是否登录，如果没有登录则重定向到认证中心。
  • 目标资源发现用户没有登录，则返回浏览器重定向地址()。(重定向地址就是cas服务端)
  • 浏览器接收到重定向的状态码(302)之后发起重定向，请求cas.pinyougou.com并且把目标资源的地址拼接在重定向的地址后   ?service=http://目标资源地址
    
    
• 定向认证：客户端会重定向用户请求到 SSO 服务器。
  
  
  • 认证中心cas.pinyougou.com接收到登录请求，返回登陆页面。
    
    
  
  

• 用户在cas.pinyougou.com的login页面输入用户名密码，提交。
• 用户认证：用户身份认证。
  
  
  • 服务器接收到用户名密码，则验证是否有效，验证逻辑可以使用cas-server提供现成的，也可以自己实现。
    
    
• 发放票据：服务器会产生一个随机的 Service Ticket。
  
  
  • cas-server认证通过后，会返回给浏览器302，重定向的地址就是之前地址service参数对应的值。后边并通过get的方式挟带了一个ticket令牌，这个ticket就是ST。
  • 同时会在Cookie中设置一个CASTGC，该cookie是网站cas.pinyougou.com的cookie，只有访问cas.pinyougou.com才会携带这个cookie过去。
  • 这
    
    
• 验证票据：服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问服务。
  
  
  • 浏览器从cas.pinyougou.com哪里拿到ticket之后，就根据指示重定向到目标资源，请求的url就是上面返回的url(带有ts的url)。
  • 目标资源在过滤器中会取到ticket的值，然后通过http方式调用cas.pinyougou.com(cas.pinyougou.com就是cas-server认证中心)验证该ticket是否是有效的。
  • cas.pinyougou.com接收到ticket之后，验证，验证通过返回结果告诉目标资源该ticket有效。
    
    
• 传输用户信息：服务器验证票据通过后，传输用户认证结果信息给客户端。
  
  
  • 目标资源接收到cas-server的返回，知道了用户合法，展示相关资源到用户浏览器上。
    
    
• 至此第一次访问的整个流程结束
• 第二次访问同一个目标资源(这次不经过cas-server)
  
  
  • 用户发起请求，访问目标资源 会经过过滤器，因为第一次访问成功后会在session中记录用户信息，因此这里直接就通过了，不用验证了。
  • 用户通过权限验证，浏览器返回正常资源。
    
    
• 访问其他互相信任的网站
  
  
  • 用户在用户中心正常上网(pinyougou-user-web) 突然想访问购物车(pinyougou-cart-web)
  • cart.pinyougou.com接收到请求，发现第一次访问，于是给他一个重定向的地址，让他去找认证中心。(同样通过?service=cart.pinyougou.com 带上参数)
  • 重定向到cas-server 因为之前访问过一次了，因此这次会携带上次返回的Cookie：TGC到认证中心。
  • 认证中心收到请求，发现TGC对应了一个TGT，于是用TGT签发一个ST，并且返回给浏览器，让他重定向到cart.pinyougou.com(地址通过service参数获得)
  • 目标资源cart.pinyougou.com获取ticket去认证中心(cas-server)验证是否有效。
  • 认证成功 返回资源并且在cart.pinyougou.com的session中设置登录状态，下次就直接登录。不必经过cas-server认证中心.
    
    
  
  

可以发现请求的时候是携带Cookie：CASTGC的，响应的就是一个地址加上TGT签发的ST也就是ticket。

然后重新重定向到目标资源这时在经过cas-server验证TS验证通过返回资源并把用户信息保持到session中

以上是CAS在不同情况下的执行流程