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

转：http://blog.csdn.net/ae6623/article/details/8848107

1）PPT流程图：ppt下载：http://pan.baidu.com/s/1o7KIlom

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

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

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

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

下面讲一下原理：

2）简易流程图：

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

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

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

1. <!-- 用于单点登录 -->
2. <filter>
3. <filter-name>CAS Filter</filter-name>
4. <filter-class>
5. edu.yale.its.tp.cas.client.filter.CASFilter
6. </filter-class>
7. <init-param>
8. <param-name>
9. edu.yale.its.tp.cas.client.filter.loginUrl
10. </param-name>
11. <param-value>
12. http://192.168.168.141:8080/casServer/login
13. </param-value>
14. </init-param>
15. <init-param>
16. <param-name>
17. edu.yale.its.tp.cas.client.filter.validateUrl
18. </param-name>
19. <param-value>
20. http://192.168.168.141:8080/casServer/serviceValidate
21. </param-value>
22. </init-param>
23. <init-param>
24. <param-name>
25. edu.yale.its.tp.cas.client.filter.serverName
26. </param-name>
27. <param-value>192.168.168.141:8080</param-value>
28. </init-param>
29. </filter>

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

client3的web.xml

1. <!-- 用于单点登录 -->
2. <filter>
3. <filter-name>CAS Filter</filter-name>
4. <filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>
5. <init-param>
6. <param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>
7. <param-value>http://192.168.168.141:8080/casServer/login</param-value>
8. </init-param>
9. <init-param>
10. <param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>
11. <param-value>http://192.168.168.141:8080/casServer/serviceValidate</param-value>
12. </init-param>
13. <init-param>
14. <param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>
15. <param-value>192.168.168.141:8080</param-value>
16. </init-param>
17. </filter>

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

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

测试二：

（3）.登录client2成功后，访问client3（同域 )

（4）.登录client3成功后，访问client2（同域 )

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

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

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的网址。

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

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

测试三：

（5）登录client2或者client3成功后，访问client4（不同域）

client4的web.xml

1. <!-- 用于单点登录 -->
2. <filter>
3. <filter-name>CAS Filter</filter-name>
4. <filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>
5. <init-param>
6. <param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>
7. <param-value>http://192.168.168.141:8080/casServer/login</param-value>
8. </init-param>
9. <init-param>
10. <param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>
11. <param-value>http://192.168.168.141:8080/casServer/serviceValidate</param-value>
12. </init-param>
13. <init-param>
14. <param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>
15. <param-value>192.168.168.141:7777</param-value>
16. </init-param>
17. </filter>

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

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

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

测试四：

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

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

1. <script type="text/javascript">
2. function validataUser() {
3. $.ajax({
4. type: "POST",
5. url: "http://192.168.168.141:8080/client3/query",
6. dataType: "json",
7. beforeSend: function(XMLHttpRequest){
8. alert("请求前");
9. },
10. success: function (data){
11. alert("跨域返回数据:" + data.userName);
12. $("#user").val(data.userName);
13. },
14. complete: function(XMLHttpRequest, textStatus){
15. alert("完成");
16. },
17. error: function(){
18. alert("错误");
19. }
20. });
21. }
22. </script>

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

测试五:

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

1. <script type="text/javascript">
2. function validataUser() {
3. $.ajax({
4. type: "POST",
5. url: "http://192.168.168.141:7777/client4/query",
6. dataType: "jsonp",
7. jsonp:"callback",
8. //url: "http://192.168.168.141:8080/client3/query",
9. //dataType: "json",
10. beforeSend: function(XMLHttpRequest){
11. alert("请求前");
12. },
13. success: function (data){
14. alert("跨域返回数据:" + data.userName);
15. $("#user").val(data.userName);
16. },
17. complete: function(XMLHttpRequest, textStatus){
18. alert("完成");
19. },
20. error: function(){
21. alert("错误");
22. }
23. });
24. }
25. </script>

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

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

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