SSO单点登录系列2:cas客户端和cas服务端交互原理动画图解,cas协议终极分析

简介: 这次的收获是把PPT也深入研究了一番。。。 上图:一会上原理分析:(本篇不涵盖cas代理认证模式,代理目前还没用到。) 文中所有资料下载地址:在文章中最下方。 1)PPT流程图: 一、用户第一次访问web1应用。

这次的收获是把PPT也深入研究了一番。。。


上图:一会上原理分析:(本篇不涵盖cas代理认证模式,代理目前还没用到。)

文中所有资料下载地址:在文章中最下方。

1)PPT流程图:


一、用户第一次访问web1应用。


img_ea785bb64a8339b6bd9df92735e35fb1.jpg

img_0361e6565528397821594ce04a51900e.jpg

img_4791d729e32ada174a79de1a5b12b171.jpg



ps:上图少画了一条线,那一条线,应该再返回来一条,然后再到server端,画少了一步。。。谢谢提醒。而且,重定向肯定是从浏览器过去的。我写的不严谨,画的比较通俗了。。。因该像下面这张图一样就ok了!!PPT自己下载下来修改吧,我就不改了。




img_8b230f9d113c453f16023617d923482b.jpg


二、用户第一次访问web2应用。


img_2ca8052e3f670bb4d9aa083ded76d577.jpg

img_75fd3d41b9ffe94cd27d5b2aac5782d7.jpg


困扰了好久的流程,其实静下进来搜个一二十篇百度上的讲解,集众家之所长,加上自己的理解,不难发现,流程理解下来很是简单。


下面讲一下原理:


img_782b5e2a477273f5dc546b19a23e7208.jpg

2)简易流程图:


一、用户第一次访问web1应用


img_23825f0463afaf824e1111711dd6d247.jpg

二、用户第一次访问web2应用

img_c1e7af431327434e7b19a523869acef4.jpg

3)文字流程:


一、用户第一次访问web1应用

1、Web1的客户端检测到session中无令牌凭证信息,将用户重定向到Cas-server端进行验证。

2、s端检测到传来的请求没有带ST参数,所以跳到Login页面进行用户登录验证。

3、s端认证结束后,生成TGT令牌和随机Ticket-ST,并且在用户的浏览器中写入Cookie-STC,随后让用户的浏览器重定向到Web1应用中,并将随机参数ST带上一起传参过去,之后Web1的cas客户端将检测到此ST参数,发送到server端进行校验,校验成功之后,服务端主动销毁此ST,并继续返回到web1应用中,web1应用此时将令牌信息写入到自己的session中,从而完成用户的单点登录认证,服务端同样的也会用一个Map记录web1加入到单点登录范围内。

4、带上ST参数重定向到web1应用。

5、web1拿到ST参数发送到s端进行校验。

6、校验成功,进入W1应用,w1将令牌凭证TGT写入session,与此同时,完成用户第一次访问应用web1的情形。


二、用户第一次访问web2应用

1、此时,用户第一次访问Web2应用,web2在自己的session中无法找到令牌信息,所以将用户重定向到S端,S端拿到用户的浏览器传来的cookie,从里面读出TGT,生成一个随机的ST,发回w2,w2拿到ST,就立即和S端进行校验,S端校验成功后,立即销毁此ST,并将web2加入到单点登录范围内,用户此时可以在Web2中进行业务操作,web2也同样的会在session中记录此令牌凭证,至此,完成用户的单点登录功能。当用户下次访问web1或者web2的时候,由于各自的session中能够拿到TGT信息,所以,只需要从中读到每次请求时所带的ST参数即可和S端进行交互,验证正确之后达到一站登录,N站访问的SSO效果。

2、w2让用户浏览器带cookie重定向到S端。

3、s端认证结束后,生成TGT令牌和随机Ticket-ST,并且在用户的浏览器中写入Cookie-STC,随后让用户的浏览器重定向到Web1应用中,并将随机参数ST带上一起传参过去,之后Web1的cas客户端将检测到此ST参数,发送到server端进行校验,校验成功之后,服务端主动销毁此ST,并继续返回到web1应用中,web1应用此时将令牌信息写入到自己的session中,从而完成用户的单点登录认证,服务端同样的也会用一个Map记录web1加入到单点登录范围内。

4、w2根据参数ST发回到s端进行校验

5、校验成功,可以访问W2,W2令牌写入session。


4)程序流程


来两段程序玩玩,打开你的火狐谷歌调试器,IE的就算了。


用Tomcat 7 搭载 cas-server 端。


用Tomcat 6 搭载你的web1和web2和web3...


之后我们开始今天的玩法




1.不登陆直接访问client2

2.不登陆直接访问client3

3.登录client2成功后,访问client3(同域 )

4.登录client3成功后,访问client2(同域 )

5.登录client2或者client3成功后,访问client4(不同域)

6.用client2去访问client3 (同域情况下用ajax拿后台的数据过来)(同域 )

7.用client2去访问client4(不同域情况下用ajax+jsonp跨域拿后台数据)(不同域 )

8.你是不是又想到了更疯狂的,来留言实验一把。


实验截图和结果以及调试分析:

测试一:

(1)不登陆直接访问client2

(2)不登陆直接访问client3

client2的web.xml

<!-- 用于单点登录 -->    <filter>        <filter-name>CAS Filter</filter-name>        <filter-class>            edu.yale.its.tp.cas.client.filter.CASFilter        </filter-class>        <init-param>            <param-name>                edu.yale.its.tp.cas.client.filter.loginUrl            </param-name>            <param-value>                http://192.168.168.141:8080/casServer/login            </param-value>        </init-param>        <init-param>            <param-name>                edu.yale.its.tp.cas.client.filter.validateUrl            </param-name>            <param-value>                http://192.168.168.141:8080/casServer/serviceValidate            </param-value>        </init-param>        <init-param>            <param-name>                edu.yale.its.tp.cas.client.filter.serverName            </param-name>            <param-value>192.168.168.141:8080</param-value>        </init-param>    </filter>

从中可以看到client2的域网址是192.168.168.141:8080,地址是http://192.168.168.141:8080/client2/


client3的web.xml


<!-- 用于单点登录 --> <filter>   <filter-name>CAS Filter</filter-name>   <filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>   <init-param>     <param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>     <param-value>http://192.168.168.141:8080/casServer/login</param-value>   </init-param>   <init-param>     <param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>     <param-value>http://192.168.168.141:8080/casServer/serviceValidate</param-value>   </init-param>   <init-param>     <param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>     <param-value>192.168.168.141:8080</param-value>   </init-param> </filter>

从中可以看到client3的域网址是192.168.168.141:8080,地址是http://192.168.168.141:8080/client3/


1.现在打开你的浏览器,抡起袖子疯狂点击我们可怜的web应用--client2,果然,直接跳到了cas的登录界面。下面的cookie里面毛都米有。

img_da62c279d0951138f8a56e8bc188bd8c.jpg

测试二:

(3).登录client2成功后,访问client3(同域 )

(4).登录client3成功后,访问client2(同域 )


1.好吧,我们输入用户名和密码,点击登录

img_8ea2ae4ee56ddf8865ff577f3f6530d2.jpg

2.来分析一下cookie。说时迟,那时快,它已经从cas的server端用户验证成功后回来了。。不仅用户验证完成,而且还不忘记拿到ST参数后,又一次发回去然后也顺利回来了。此时已经完成了用户的单点登录。


img_dd5bc1c4107c37c6f17d765f495f6cfb.jpg

3.顺利登录成功之后,我们清除一下火狐的网络信息,来直接点击超链接访问client3,

之前的ST,我们记录一下:ST-5-beGeNw5zW0x56vpnmotG-cas01.example.org

此时得到了一个ST : ST-4-jkFHgkJkvTZVJt22SUNV-cas01.example.org

啧啧,ST果然是不一致的


言归正传,分析一下。


因为我们是在client2里面点击的超链接的形式访问的client3,所以ST参数肯定带过去了,Server端一查,哎呦,你小子有ST,我来检测一下,我靠,居然是正确的ST,好吧,允许你通过,此时,用户神不知鬼不觉,感觉犹如神助一般,进入了client3


4.那么我们来测试一下,直接在成功登录了client2之后,浏览器里输入clint3的网址。


img_8720980e80c7a8dc7786338910313187.jpg

img_840fbc6ad2e4f183b38512ae491e92ed.jpg

从网络分析抓包里我们可以看到,也是这两个请求,和点击了超链接到client3一样的两个请求。。


说明server端已经拿到了用户的浏览器中的cookie,并且生成了ST给client3,client3也已经和server端交互结束,包括验证ST,而这一切,肉眼果然看不出来。


测试三:

(5)登录client2或者client3成功后,访问client4(不同域)


client4的web.xml

<!-- 用于单点登录 --> <filter>   <filter-name>CAS Filter</filter-name>   <filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>   <init-param>     <param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>     <param-value>http://192.168.168.141:8080/casServer/login</param-value>   </init-param>   <init-param>     <param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>     <param-value>http://192.168.168.141:8080/casServer/serviceValidate</param-value>   </init-param>   <init-param>     <param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>     <param-value>192.168.168.141:7777</param-value>   </init-param> </filter>

从中可以看到client2的域网址是192.168.168.141:7777,地址是http://192.168.168.141:7777/client4/


img_1d4c3e5d7c592a164e98899d429cffb7.jpg

已经带cookie验证之后,接到ST参数ticket,然后和server端验证结束。完成了client4的登录。


下面我们开始研究ajax异步获取数据的方式,看看异步的情况下,cas有没有失效。


测试四:

(6)用client2去访问client3 (同域情况下用ajax拿后台的数据过来)(同域 )

先登录client2,然后不登陆client3的情况下,用ajax传数据到后台,后天生成json传回前台,这个过程我分析一下。

<script type="text/javascript">        function validataUser() {            $.ajax({                    type: "POST",                    url: "http://192.168.168.141:8080/client3/query",                    dataType: "json",                    beforeSend: function(XMLHttpRequest){                        alert("请求前");                    },                    success: function (data){            alert("跨域返回数据:" + data.userName);                        $("#user").val(data.userName);                    },        complete: function(XMLHttpRequest, textStatus){                                 alert("完成");                    },        error: function(){                 alert("错误");                    }            });        }        </script>


ajax虽然是异步的,但是也算是发了一个请求,跟我们直接登录了client2之后,打开新的标签页,直接输入网址是一个效果(同测试二中的第4步),client3会在自己的session中检测有没有令牌凭证,如果没有,直接跑到cas-server端,server端拿到cookie,判断已经登录,就生成ST给client3,然后client3拿着这个ST去cas-server端校验,验证成功后,响应用户的ajax请求,把数据返回过来。


img_420eae6021440e1edb9e37ecfaf7b9f6.jpg


img_6473fab855f3551560909859d6c6d557.jpg


测试五:


(7)用client2去访问client4(不同域情况下用ajax+jsonp跨域拿后台数据)(不同域 )


<script type="text/javascript">            function validataUser() {                $.ajax({                        type: "POST",                        url: "http://192.168.168.141:7777/client4/query",                        dataType: "jsonp",                        jsonp:"callback",                        //url: "http://192.168.168.141:8080/client3/query",                        //dataType: "json",                        beforeSend: function(XMLHttpRequest){                            alert("请求前");                        },                        success: function (data){            alert("跨域返回数据:" + data.userName);                            $("#user").val(data.userName);                        },                                         complete: function(XMLHttpRequest, textStatus){                                     alert("完成");                        },            error: function(){                     alert("错误");                        }                });            }            </script>



img_5835d90ee7d3e51f69128c8f755ab7c0.jpg


不知不觉就又是一趟流程,client4此时也被记录到cas-server端,加入单点登录的范围。下次再来的时候就直接在client4的客户端过滤器里面检测session即可。


至此,已经彻底测试了7种情况,跨域和不跨域都有所涉及。下篇我们将开始对cas-server端的征程,包括对服务端常用核心源码的研究以及关于多数据库之间的配置,之后便是DIY自定义登录页面。


文中所有资料下载地址:http://download.csdn.net/detail/ae6623/5303255

程序端配置:如果自己没有oracle和mysql请注销掉C:\tomcat7\webapps\casServer\WEB-INF\deployerConfigContext.xml中的相关配置,否则会报mysql数据源找不到或者oracle加载错误的报告。这个源码一定要配合我的文章,否则你无法运行。

2013年4月25日9:52:11

qq 394263788

目录
相关文章
|
10月前
|
存储 XML Java
网络基础 CAS协议学习总结
网络基础 CAS协议学习总结
249 0
|
存储 JSON 数据安全/隐私保护
Jasny SSO是如何实现的?底层原理是什么?
Jasny SSO是如何实现的?底层原理是什么?
|
存储 缓存 数据安全/隐私保护
Jasny SSO是如何处理用户会话的?底层原理是什么?
Jasny SSO是如何处理用户会话的?底层原理是什么?
|
安全 网络安全 数据安全/隐私保护
Jasny SSO是如何处理安全性问题的?底层原理是什么?
Jasny SSO是如何处理安全性问题的?底层原理是什么?
|
NoSQL 前端开发 JavaScript
单点登录和CAS解决方案入门
单点登录和CAS解决方案入门
317 0
单点登录和CAS解决方案入门
|
Java 应用服务中间件
CAS单点登陆原理简介及环境搭建(3)
CAS单点登陆原理简介及环境搭建(3)
122 0
CAS单点登陆原理简介及环境搭建(3)
|
应用服务中间件 数据库
CAS单点登陆原理简介及环境搭建(2)
CAS单点登陆原理简介及环境搭建(2)
148 0
CAS单点登陆原理简介及环境搭建(2)
|
应用服务中间件 数据安全/隐私保护
CAS单点登陆原理简介及环境搭建(1)
CAS单点登陆原理简介及环境搭建(1)
184 0
CAS单点登陆原理简介及环境搭建(1)
|
存储 NoSQL 安全
单点登录原理与简单实现
1、http无状态协议 web应用采用browser/server架构,http作为通信协议。http是无状态协议,浏览器的每一次请求,服务器会独立处理,不与之前或之后的请求产生关联,这个过程用下图说明,三次请求/响应对之间没有任何联系
单点登录原理与简单实现
|
Java 数据安全/隐私保护
单点登录终极方案之 CAS 应用及原理
Cookie的单点登录的实现方式很简单,但是也问题颇多。例如:用户名密码不停传送,增加了被盗号的可能。另外,不能跨域!
单点登录终极方案之 CAS 应用及原理