黑马程序员技术交流社区
标题: 【南京校区】 关于CAS的执行流程 [打印本页]
作者: 大蓝鲸小蟀锅 时间: 2018-12-14 15:57
标题: 【南京校区】 关于CAS的执行流程
本帖最后由 大蓝鲸小蟀锅 于 2018-12-14 15:59 编辑
详细探究 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的原理 (执行流程):
用户在cas.pinyougou.com的login页面输入用户名密码,提交。
用户认证:用户身份认证。
发放票据:服务器会产生一个随机的 Service Ticket。
验证票据:服务器验证票据 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)
访问其他互相信任的网站
用户在用户中心正常上网(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在不同情况下的执行流程
欢迎光临 黑马程序员技术交流社区 (http://bbs.itheima.com/) |
黑马程序员IT技术论坛 X3.2 |