CAS (4) —— CAS浏览器SSO访问顺序图详解(CAS Web Flow Diagram by Example)
2015-12-15 16:18
615 查看
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)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/dc8edba47eb57de4d951afb1f4fc8c4f.png)
详细信息如下:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/02bff8e0d8b0cc2885891a67430f0118.png)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/0b975a0811fbd72aa818fb6aa79e8dfb.png)
点击“高级”,选择“继续前往app1.hoau.com(不安全)”
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/61750b716abb209fce098a05f23d26ea.png)
Response Header中,
app1服务将请求重定向(redirect)到CAS服务。
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/45922799ca93dfb6d4cdf28a120bf130.png)
* 注意:此时客户端浏览器中可能仍然带有Cookie信息TGC与CASPRIVACY,但是在Response Header中发现,服务器会将这两个Cookie置空,并且返回一个JSESSIONID
此时,CAS服务器发现用户没有SSO的Session。
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/74fdd259051989045781523d778875d1.png)
Form:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/918ebf2c5074f0df1ebeb0c1b829c31b.png)
TGC:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/a1725ec8743bc19fe52bf441b42cbd51.png)
然后CAS服务器会对提交的用户名密码进行验证,如果验证通过。
创建CASTGC Cookie(这里图中为TGC)
*注意:这个Session级别的Cookie 包含Ticket Granting Ticket(TGT)的信息。
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/5529fd29c02e4a225cfe957b032964aa.png)
最后这条请求的响应会同样通过“302 Found”,将
这时,浏览器会带上获得的ticket向App重新请求登陆,
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/19304599e3b093ea118e26d40b748228.png)
* 此处(8)、(9)两步使用TCPMon接获消息查看
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/04eaef0e8d317a6d3d153e2ca3c227fc.png)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/b00784d0ae15f52abc24aa2373678901.png)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/8de011b7edd2f49422ef2a30c25845bf.png)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/4dd4bffcca1312facd66bcfd0e73ad9f.png)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/a5c722a1fad7f44d66ac2ea0925c0af9.png)
发现再次访问时,实际上有4段请求,与首次访问唯一不同的是少掉了用户名和密码的输入过程,但是Protected App上关于Session Cookie的校验并没有通过。
可以看到下图中Protected App在(1)时又将浏览器重定向了CAS服务器,并且又为客户端生成了新的Ticket
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/1229fead9891946598d758df8631b826.png)
发现经过上面4段请求验证后,浏览器url上会带上jsessionid,如果将此请求参数删除,那么会重新经过4段请求。
如果不删除,而直接刷新页面,系统交互的行为则如官网上顺序图描述的行为一致。
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/44fdcc4e102e62a1a94dd8ceb49014ff.png)
结
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/8fd4d2a6be3901af5b02632ceaeeda0e.png)
果仍然无效,还是4段请求。
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/68ab7132481c9d8942013c27ee63c7dc.png)
而Firefox浏览器会有些差异,在删除url后的jsessionid后,Firefox的下次请求仍然带有cookie
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/7b9a327401ecf2cb7496d16f8aef4a8a.png)
然后尝试去掉url后的jsessionid参数,再次访问
终于得到了我们想要的结果
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/d26cc57bd7cbd1655e880d28787d059c.png)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/50e44e520a8219a4af26e2570ef16304.png)
如图,我们可以发现CAS服务器已经生成了CASTGC,这个值会再访问另一应用时使用到。
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/90f353aff79d2a21f5abda5892dc44c3.png)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/e72adb2c0855f0008e9d9a0d9f8d644d.png)
这时
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/a5711a528803e09310421dbc79b29265.png)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/1e585f5ed87ba8e42eda35193c63c598.png)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/1fcedac2636bdd9b9271589e9e1f30a2.png)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/21496bf372ee475b736242d4672bf7c7.png)
然后
* 此处(6)、(7)两步使用TCPMon接获消息查看,由于测试时忘记配TCPMon了,可能某些参数值对不上,在此致歉
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/3c2e223fadf68694aed5cecadd04c785.png)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/96c1d204ff6c224c6c083b3ceb38998a.png)
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)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/dc8edba47eb57de4d951afb1f4fc8c4f.png)
(1)用户首次访问(GET: https://app1.hoau.com:8413/cas1)
由于ssl是本地配置,浏览器不信任当前证书,所以会提示"NET::ERR_CERT_AUTHORITY_INVALID"详细信息如下:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/02bff8e0d8b0cc2885891a67430f0118.png)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/0b975a0811fbd72aa818fb6aa79e8dfb.png)
点击“高级”,选择“继续前往app1.hoau.com(不安全)”
(2)此时访问未经身份验证(unauthenticated)
所以服务器将请求转到CAS,同时加上查询参数“service”。如何实现的呢?
我们可以看到http GET请求的Header中返回的状态码是“302 Found”Request URL: https://app1.hoau.com:8413/cas1 Status Code: 302 Found
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/61750b716abb209fce098a05f23d26ea.png)
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
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/45922799ca93dfb6d4cdf28a120bf130.png)
* 注意:此时客户端浏览器中可能仍然带有Cookie信息TGC与CASPRIVACY,但是在Response Header中发现,服务器会将这两个Cookie置空,并且返回一个JSESSIONID
JSESSIONID=8534DCE475C44FF446D1DE2250426B1F
此时,CAS服务器发现用户没有SSO的Session。
(4)所以返回登录页面
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/74fdd259051989045781523d778875d1.png)
(5)登陆SSO(用户名/密码:test01/psw01)
可以注意到此时是用POST方法将用户名和密码,包括登陆的Ticket一起发到CAS服务器Form:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/918ebf2c5074f0df1ebeb0c1b829c31b.png)
TGC:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/a1725ec8743bc19fe52bf441b42cbd51.png)
然后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
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/5529fd29c02e4a225cfe957b032964aa.png)
最后这条请求的响应会同样通过“302 Found”,将
(7)浏览器重定向到Protected App
Location:https://app1.hoau.com:8413/cas1? ticket=ST-1-RNCht4LbpbALUYWPnR7K-cas01.sso.hoau.com
这时,浏览器会带上获得的ticket向App重新请求登陆,
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/19304599e3b093ea118e26d40b748228.png)
(8)Protected App收到请求后
会向CAS服务器发送请求,验证ticket的合法性(9)然后CAS服务器会返回一个XML内容
(包括成功信息,认证对象和一些其他可选参数)* 此处(8)、(9)两步使用TCPMon接获消息查看
(10)如果成功,Protected App会相应(7)的请求
通过“302 Found”将浏览器重定向到Protected App的目标页面,同时设置Cookie的JSESSIONIDContent-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
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/04eaef0e8d317a6d3d153e2ca3c227fc.png)
(11)浏览器带Cookie:JSESSIONID访问目标应用的页面
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/b00784d0ae15f52abc24aa2373678901.png)
(12)登陆成功,Protected App返回状态码200与页面内容
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/8de011b7edd2f49422ef2a30c25845bf.png)
再次访问同一应用
顺序图:(来源于http://jasig.github.io/cas/4.0.x/protocol/CAS-Protocol.html)![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/4dd4bffcca1312facd66bcfd0e73ad9f.png)
(1)浏览器带第一次认证后的Cookie:JSESSIONID访问Protected App
(2)Protected App校验Session Cookie
如果成功则返回首页。但是在测试时遇到了问题
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/a5c722a1fad7f44d66ac2ea0925c0af9.png)
发现再次访问时,实际上有4段请求,与首次访问唯一不同的是少掉了用户名和密码的输入过程,但是Protected App上关于Session Cookie的校验并没有通过。
可以看到下图中Protected App在(1)时又将浏览器重定向了CAS服务器,并且又为客户端生成了新的Ticket
“ticket=ST-4-s2ffmz3oJZTax5XMV4x7-cas01.sso.hoau.com”
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/1229fead9891946598d758df8631b826.png)
* 怀疑Protected App没有维持Session的状态
为了验证这个想法,我们重新访问https://app1.hoau.com:8413/cas1
发现经过上面4段请求验证后,浏览器url上会带上jsessionid,如果将此请求参数删除,那么会重新经过4段请求。
如果不删除,而直接刷新页面,系统交互的行为则如官网上顺序图描述的行为一致。
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/44fdcc4e102e62a1a94dd8ceb49014ff.png)
尝试修改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>
结
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/8fd4d2a6be3901af5b02632ceaeeda0e.png)
果仍然无效,还是4段请求。
尝试更换浏览器进行测试
发现IE内核的浏览器行为,和我们之前测试用的Chrome一致,如果删除url后的jsessionid,那么同样会经过4段请求。![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/68ab7132481c9d8942013c27ee63c7dc.png)
而Firefox浏览器会有些差异,在删除url后的jsessionid后,Firefox的下次请求仍然带有cookie
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/7b9a327401ecf2cb7496d16f8aef4a8a.png)
* 怀疑浏览器Cookie写权限设置有问题
在Chrome浏览器中,“设置->高级->隐私设置->内容设置->Cookie”中管理例外情况,将app1.hoau.com和sso.hoau.com同时加入到例外设置中,然后尝试去掉url后的jsessionid参数,再次访问
https://app1.hoau.com:8413/cas1
终于得到了我们想要的结果
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/d26cc57bd7cbd1655e880d28787d059c.png)
访问同域另一应用
顺序图:(来源于http://jasig.github.io/cas/4.0.x/protocol/CAS-Protocol.html)![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/50e44e520a8219a4af26e2570ef16304.png)
(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
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/90f353aff79d2a21f5abda5892dc44c3.png)
(1)访问另一应用
https://app2.hoau.com:8423/cas2
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/e72adb2c0855f0008e9d9a0d9f8d644d.png)
这时
(2)Protected App #2无法对用户进行认证
服务器返回重定向状态码“302 Found”,将浏览器重定向到CAS服务器Location:"https://sso.hoau.com:8433/cas/login?service=https%3A%2F%2Fapp2.hoau.com%3A8423%2Fcas2"
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/a5711a528803e09310421dbc79b29265.png)
(3)浏览器尝试访问CAS服务器
并携带当前的Session和场景一中通过App #1认证时获取的Cookie CASTGChttps://sso.hoau.com:8433/cas/login?service=https://app2.hoau.com:8423/cas2
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/1e585f5ed87ba8e42eda35193c63c598.png)
(4)CAS服务器验证Ticket并重定向
由于CAS服务器仍然存有之前CASTGC的状态,因此将浏览器再次重定向到应用#2Location:"https://app2.hoau.com:8423/cas2? ticket=ST-58-TilmxEy20VOmDQuSdIx1-cas01.sso.hoau.com"
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/1fcedac2636bdd9b9271589e9e1f30a2.png)
(5)浏览器通过重定向访问应用#2的地址
https://app2.hoau.com:8423/cas2
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/21496bf372ee475b736242d4672bf7c7.png)
然后
(6)Protected App #2会向CAS服务器再次发起请求
此时会携带Protected App #2生成的ticketticket=ST-58-TilmxEy20VOmDQuSdIx1-cas01.sso.hoau.com
(7)如果验证成功,CAS服务器会返回包含成功信息的xml内容相应
并且将浏览器重定向到Protected App #2的登陆后页面* 此处(6)、(7)两步使用TCPMon接获消息查看,由于测试时忘记配TCPMon了,可能某些参数值对不上,在此致歉
(8)Protected App #2的验证通过后,尝试重定向到登陆成功的页面
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/3c2e223fadf68694aed5cecadd04c785.png)
(9)浏览器携带CAS的Cookie请求App #2的登陆成功页
Protected App #2再次校验Session Cookie(10)如果验证成功,则返回登陆成功页面的内容
![](https://oscdn.geek-share.com/Uploads/Images/Content/202004/15/96c1d204ff6c224c6c083b3ceb38998a.png)
结束
相关文章推荐
- 贪婪匹配和非贪婪匹配
- Thread及Runnable的使用方式简介
- angular发送multipart/form-data文件的方法
- ajax执行domino代理并返回数据(Get方法)
- 数据库学习笔记
- ClipDrawable 截取图片片段实现缓缓加载图片
- DNS服务器搭建
- Assembly x64 Intro - View Assemble Variable by GDB
- Android开发笔记(十九)底部标签栏TabBar
- 7 Steps for becoming Deep Learning Expert 成为深度学习专家的七个步骤
- 求个懂bro里binpac解析的兄弟
- C语言getopt()函数的使用
- ASP.NET MVC 使用Jquery Ajax实现登录
- T4模板提示错误--包含类功能的模板必须以类功能结尾
- 【私人定制jackson】定制jackson的自定义序列化(null值的处理)
- nginx图片服务器配置
- 摄像头模组基础扫盲
- Android崩溃(一):小红点BadgeView导致的崩溃
- 简单的猜数游戏
- 客户端认证自签名HTTPS证书