CAS (4) —— CAS浏览器SSO访问顺序图详解（CAS Web Flow Diagram by Example）

CAS (4) —— CAS浏览器SSO访问顺序图详解（CAS Web Flow Diagram by Example）

tomcat版本: tomcat-8.0.29

jdk版本: jdk1.8.0_65

nginx版本: nginx-1.9.8

cas版本: cas4.1.2
cas-client-3.4.1

参考来源:

jasig.github.io:CAS protocol

CAS (1) —— Mac下配置CAS到Tomcat（服务端）

CAS (2) —— Mac下配置CAS到Tomcat（客户端）

Cas（01）——简介

Cas（09）——通过Proxy访问其它Cas应用

顺序图：(来源于http://jasig.github.io/cas/4.0.x/protocol/CAS-Protocol.html)

（1）用户首次访问（GET: https://app1.hoau.com:8413/cas1）

由于ssl是本地配置，浏览器不信任当前证书，所以会提示"NET::ERR_CERT_AUTHORITY_INVALID"
详细信息如下：

点击“高级”，选择“继续前往app1.hoau.com(不安全)”

（2）此时访问未经身份验证（unauthenticated）

所以服务器将请求转到CAS，同时加上查询参数“service”。

如何实现的呢？

我们可以看到http GET请求的Header中返回的状态码是“302 Found”

Request URL: https://app1.hoau.com:8413/cas1
Status Code: 302 Found

Response Header中，

Location:https://sso.hoau.com:8433/cas/login?service=https%3A%2F%2Fapp1.hoau.com%3A8413%2Fcas1

app1服务将请求重定向（redirect）到CAS服务。

（3）浏览器向CAS服务器发起带参数的请求

Location:https://sso.hoau.com:8433/cas/login?service=https%3A%2F%2Fapp1.hoau.com%3A8413%2Fcas1

* 注意：此时客户端浏览器中可能仍然带有Cookie信息TGC与CASPRIVACY，但是在Response Header中发现，服务器会将这两个Cookie置空，并且返回一个JSESSIONID
JSESSIONID=8534DCE475C44FF446D1DE2250426B1F

此时，CAS服务器发现用户没有SSO的Session。

（4）所以返回登录页面

（5）登陆SSO（用户名/密码：test01/psw01）

可以注意到此时是用POST方法将用户名和密码，包括登陆的Ticket一起发到CAS服务器

Form：

TGC：

然后CAS服务器会对提交的用户名密码进行验证，如果验证通过。

（6）CAS服务器会做几件事情

  • 创建SSO Session
  • 创建CASTGC Cookie（这里图中为TGC）
*注意：这个Session级别的Cookie 包含Ticket Granting Ticket（TGT）的信息。
Set-Cookie:TGC=eyJhbGciOiJIUzUxMiJ9.ZXlKaGJHY2lPaUprYVhJaUxDSmxibU1pT
2lKQk1USTRRMEpETFVoVE1qVTJJbjAuLmNFck5Eb2FkWGZkQndvMDBCN2gwNmcuU0
NlVjVaSllVTjJZbmNuRURmQjdUR2tPNGZ4Ny14RXAtZnctYWRhQlBUOU4wYS1ZU0d
PaE12MXNUUkxmRG1sYVV0U1NQM0prQzBrNERUOFZvd2dJU0VmYVBMdzFGdFNtdGhp
ZDN3cE1iVHZzbUlmOXFQYkZ3Q0F3eW9Pd3pjRmJHN1hzSHI2MHBhYjh5bFZzbHhPa
W12WlpRQnJveFpVR3hRQTJ1ZVZhbkNnQ09vYkxSY0RfQ0NOQnJ4Mm5aN19ocFJOYk
Z1LVZRdTV3c2FxUmxKTS05LWFGc1otQXBPWENXOEhjQlREUHBvOUVqWFhDZ204T00
xMXUtSldKdDBCRy1BVkl0ZUlKT0FGY3VoMXd4RWdYX0EuZUQzYjRGUkhKby1IamlC
bmNnMDlPZw.WwEL14ipWvub5c2PoE-Xq38I1ssN1glPclnXA7rKt7aV0boWAuR9WaUT8lPdMeL3ycjEv0whYAnaetv_hid0
8A; Path=/cas/; Secure; HttpOnly

最后这条请求的响应会同样通过“302 Found”，将

（7）浏览器重定向到Protected App

Location:https://app1.hoau.com:8413/cas1?
ticket=ST-1-RNCht4LbpbALUYWPnR7K-cas01.sso.hoau.com

这时，浏览器会带上获得的ticket向App重新请求登陆，

（8）Protected App收到请求后

会向CAS服务器发送请求，验证ticket的合法性

（9）然后CAS服务器会返回一个XML内容

（包括成功信息，认证对象和一些其他可选参数）

* 此处（8）、（9）两步使用TCPMon接获消息查看

（10）如果成功，Protected App会相应（7）的请求

通过“302 Found”将浏览器重定向到Protected App的目标页面，同时设置Cookie的JSESSIONID

Content-Length:0
Date:Tue, 15 Dec 2015 01:56:41 GMT
Location:https://app1.hoau.com:8413/cas1;jsessionid=3D16483C31F8358A561E8EDCCC1C196D.tomcat1
Server:Apache-Coyote/1.1
Set-Cookie:JSESSIONID=3D16483C31F8358A561E8EDCCC1C196D.tomcat1; Path=/cas1/; Secure; HttpOnly

（11）浏览器带Cookie:JSESSIONID访问目标应用的页面

（12）登陆成功，Protected App返回状态码200与页面内容

再次访问同一应用

顺序图：(来源于http://jasig.github.io/cas/4.0.x/protocol/CAS-Protocol.html)

（1）浏览器带第一次认证后的Cookie:JSESSIONID访问Protected App

如果成功则返回首页。

但是在测试时遇到了问题

发现再次访问时，实际上有4段请求，与首次访问唯一不同的是少掉了用户名和密码的输入过程，但是Protected App上关于Session Cookie的校验并没有通过。

可以看到下图中Protected App在（1）时又将浏览器重定向了CAS服务器，并且又为客户端生成了新的Ticket

“ticket=ST-4-s2ffmz3oJZTax5XMV4x7-cas01.sso.hoau.com”

* 怀疑Protected App没有维持Session的状态

为了验证这个想法，我们重新访问

https://app1.hoau.com:8413/cas1

发现经过上面4段请求验证后，浏览器url上会带上jsessionid，如果将此请求参数删除，那么会重新经过4段请求。

如果不删除，而直接刷新页面，系统交互的行为则如官网上顺序图描述的行为一致。

尝试修改Protected App端的设置web.xml

增加SingleSignOutFilter

<filter>
	<filter-name>CAS Single Sign Out Filter</filter-name>
	<filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class>
</filter>

<filter-mapping>
	<filter-name>CAS Single Sign Out Filter</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>

<listener>
	<listener-class>org.jasig.cas.client.session.SingleSignOutHttpSessionListener</listener-class>
</listener>

结

果仍然无效，还是4段请求。

尝试更换浏览器进行测试

发现IE内核的浏览器行为，和我们之前测试用的Chrome一致，如果删除url后的jsessionid，那么同样会经过4段请求。

而Firefox浏览器会有些差异，在删除url后的jsessionid后，Firefox的下次请求仍然带有cookie

* 怀疑浏览器Cookie写权限设置有问题

在Chrome浏览器中，“设置->高级->隐私设置->内容设置->Cookie”中管理例外情况，将app1.hoau.com和sso.hoau.com同时加入到例外设置中，

然后尝试去掉url后的jsessionid参数，再次访问

https://app1.hoau.com:8413/cas1

终于得到了我们想要的结果

访问同域另一应用

顺序图：(来源于http://jasig.github.io/cas/4.0.x/protocol/CAS-Protocol.html)

（0）在访问Protected App之后

https://app1.hoau.com:8413/cas1

如图，我们可以发现CAS服务器已经生成了CASTGC，这个值会再访问另一应用时使用到。

eyJhbGciOiJIUzUxMiJ9.ZXlKaGJHY2lPaUprYVhJaUxDSmxibU1pT2lKQk1USTRR
MEpETFVoVE1qVTJJbjAuLndBeWRVeGpIODE4Z0I4X29DSFBXYXcuVHVaOE5BN0tQZ
GJlSU5NSUZjNGZSQUVacDdUeGFFQkNJU2FONVFEYVRrVUpYR3VyUlpDeEloTktxTF
ljci1jNGJVdjdQLWc5MW9uaEUtU0VNSHV4RUU4dGpMeDRtMkg0RGNWbFJyTkJiR0N
EOUljSzNNZFZjV1BCRDduSFpwZ3E5VmI1emJMRV9GSmJjY1ZwZU5QdXRhOEp0M1g4
b0NLVjQzanozeHA1WlRfR0xkdjdmdjZlMmtEMnBTRXRIOG5UcS04NFpmNFlEcGZ4c
1Z2WDhlMVZLb0ZRcndyWUJpdGpnU0c4TkxPVHB5dy5TQURjZmN2cGhnbkJJT0NKNl
RLd1pB.hsIsZNJHWfrqQJ3kj4z18WctFpxeVPDQv9ONeK4yRVRSNBNprlfYJ_toa9
hbNozf_rGYOYySEdMJbSvR5IMa-A

（1）访问另一应用

https://app2.hoau.com:8423/cas2

这时

（2）Protected App #2无法对用户进行认证

服务器返回重定向状态码“302 Found”，将浏览器重定向到CAS服务器

Location:"https://sso.hoau.com:8433/cas/login?service=https%3A%2F%2Fapp2.hoau.com%3A8423%2Fcas2"

（3）浏览器尝试访问CAS服务器

并携带当前的Session和场景一中通过App #1认证时获取的Cookie CASTGC

https://sso.hoau.com:8433/cas/login?service=https://app2.hoau.com:8423/cas2

（4）CAS服务器验证Ticket并重定向

由于CAS服务器仍然存有之前CASTGC的状态，因此将浏览器再次重定向到应用#2

Location:"https://app2.hoau.com:8423/cas2?
ticket=ST-58-TilmxEy20VOmDQuSdIx1-cas01.sso.hoau.com"

（5）浏览器通过重定向访问应用#2的地址

https://app2.hoau.com:8423/cas2

然后

（6）Protected App #2会向CAS服务器再次发起请求

此时会携带Protected App #2生成的ticket

ticket=ST-58-TilmxEy20VOmDQuSdIx1-cas01.sso.hoau.com

（7）如果验证成功，CAS服务器会返回包含成功信息的xml内容相应

并且将浏览器重定向到Protected App #2的登陆后页面

* 此处（6）、（7）两步使用TCPMon接获消息查看，由于测试时忘记配TCPMon了，可能某些参数值对不上，在此致歉

（8）Protected App #2的验证通过后，尝试重定向到登陆成功的页面

（9）浏览器携带CAS的Cookie请求App #2的登陆成功页

Protected App #2再次校验Session Cookie

（10）如果验证成功，则返回登陆成功页面的内容

结束

posted @ 2015-12-15 16:18  Richaaaard  阅读(4021)  评论(3)  编辑  收藏  举报