最新要闻

广告

手机

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

家电

网络基础 CAS协议学习总结_天天新资讯

来源:博客园

架构介绍

系统组件

CAS服务器和客户端构成了CAS系统体系结构的两个物理组件,它们通过各种协议进行通信。

CAS服务器

CAS服务器是基于Spring Framework构建的Java servlet,其主要职责是通过签发和验证ticket来验证用户并授予对启用CAS认证了的服务(通常称为CAS客户端)的访问权限。当用户成功登录(即认证通过)时,CAS服务器会向用户签发TGT(Ticket Granting Ticket),并创建SSO会话。应用户的请求,通过使用TGT作为令牌的浏览器重定向,向启用CAS认证的服务签发ST(Service Ticket)。ST随后通过调用接口在CAS服务器上进行验证。这些交互作用在CAS协议文档中有详细描述。

CAS客户端

术语“CAS客户端”在其常见用法中有两个不同的含义。CAS客户端是任何启用CAS认证的应用,可通过支持的协议与CAS服务器通信。CAS客户端也是一个软件包,可以与各种软件平台和应用程序集成,以便通过某些身份验证协议(例如CAS、SAML、OAuth)与CAS服务器通信。CAS客户端支持多种软件平台和并且已经开发了很多产品。


【资料图】

CAS协议

CAS协议是一种简单而强大的基于票证(ticket)的协议。完整的协议规范可以查看这里。

它涉及一个或多个客户端和一个服务器。客户端嵌入在CAS化的(CASified)应用程序中(称为“CAS服务”),而CAS服务器则是一个独立的组件:

  • CAS服务器负责对用户进行身份验证并授予对应用程序的访问权限

  • CAS客户端保护CAS应用程序并从CAS服务器检索授权用户的身份。

关键概念:

  • TGT(Ticket Granting Ticket), 存储在 TGCcookie中,为SSO(Single Sign On, 单点登录,)会话的Key,代表某个用户的某个SSO会话。
  • TGC(Ticket Granted Cookie),以TGT为值的Cookie
  • ST(Service Ticket,服务票证), 作为GETURL请求参数传输,表示由CAS服务器授予给特定用户对CAS服务的访问权限。

单点登录:指在多个应用系统中,只需登录一次,即可在多个应用系统之间共享登录。

协议版本

3.0.3

当前的CAS协议版本是“3.0.3”。协议规范说明可参考连接 https://apereo.github.io/cas/6.6.x/protocol/CAS-Protocol-Specification.html,由Apereo CAS服务实现,作为官方参考实现。在CAS协议“2.0”之上增加了最常见的增强功能。在其他功能中,版本“2.0”和“3.0”之间最引人注目的更新是能够通过新的/p3/serviceValidate端点返回身份验证/用户属性。

2.0

协议规范说明,可参考连接 https://apereo.github.io/cas/6.6.x/protocol/CAS-Protocol-V2-Specification.html

Web流程图

过程详述

  1. 用户通过浏览器访问被保护的应用(暂且称之为 应用服务)

    GET https://app.example.com/
  2. 应用服务上的CAS客户端检测到用户需要进行身份认证时,携应用返回302响应状态码,指示浏览器重定向到CAS服务器。

    说明:CAS客户端包含一个AuthenticationFilter过滤器,该过滤器可以拦截所有的请求,用于判断用户是否需要通过Cas Server进行身份认证,如果需要则将跳转到CAS服务器登录页面,否则则请求会继续往下执行

    关键响应头

    location: https://cas.example.com/cas/login?service=https%3A%2F%2Fapp.example.com%2F

    其中,service指向用户原访问地址(注意,是经过URL编码后的地址)

  3. 浏览器根据302响应状态码及响应头location指示,自动重定向访问CAS服务器。

    GET https://cas.example.com/cas/login?service=https%3A%2F%2Fapp.example.com%2F
  4. CAS服务器未检测到SSO会话,向用户返回CAS登录表单页面。

  5. 用户手动输入正确用户名,密码等认证信息后,提交表单

    POST https://cas.example.com/cas/login?service=https%3A%2F%2Fapp.example.com%2F
  6. CAS服务器接收到用户名和密码后,对用户进行验证(可使用CAS服务器默认的验证,也可以自定义实现验证方法),如果验证通过,则创建SSO会话,签发一个ST(作为location请求中URL参数传输) , 返回302响应状态码,及location请求头,提示浏览器重定向访问应用服务。

    关键响应头

    Location: https://app.example.com/?ticket=ST-12345678Set-Cookie: CASTGC=TGT-2345678

    说明:Set-Cookie响应头,提示浏览器存储Cookie--将TGT(Ticket Granted Ticket)存储为CASTGCCookie值,这是单点登录的关键步骤,因为这样以后,当前浏览器中访问其它需要CAS认证的应用服务时,将自动携带CASTGCCookie重定向访问CAS服务器网站,而访问CAS服务器时,CAS服务会通过该Cookie值,即TGT来查找对应的SSO会话,如果存在会话,则表示已登录CAS服务器,签发ST, 返回302响应状态码,提示浏览器重定向访问应用服务,否则未登录,返回CAS服务器登录页。

    注意,CASTGC也可能被命名为其它类似名称,比如 CASTGC-D,如果有对CAS服务器进行相关改造的话。

  7. 浏览器根据302响应状态码及响应头location指示,自动重定向访问 应用服务。

    GET https://app.example.com/?ticket=ST-12345678
  8. 应用服务收到请求后,请求CAS服务器服务验证接口,验证ST

    注意:每个ST只能用一次,且存在有效期,这就是为啥需要二次访问CAS服务器进行验证的原因。

    GET https://cas.example.com/serviceValidate?service=https%3A%2F%2Fapp.example.com%2F&ticket=ST-12345678
  9. CAS服务器对ST进行验证,生成XML响应报文,返回给应用服务,该XML响应报文包含是包含是否验证成功、被认证的用户信息、可选属性。

  10. 应用服务收到响应报文后,可根据CAS服务器验证结果,为当前用户生成会话,返回302响应状态码,Set-Cookielocation响应头,提示浏览器存储会话Cookie,并再次通过重定向访问应用服务。

    关键响应头:

    Set-Cookie: JSESSIONID=ABC1234567Location: https://app.example.com/

    注意:上述Location中的URL,没有携带ticket参数,避免长时间将ST暴露在浏览器地址栏中

  11. 用户浏览器收到响应后,根据提示重定向访问应用服务

    GET https://app.example.com/Cookie: JSESSIONID=ABC1234567
  12. 应用服务收到上述请求后,验证会话Cookie,如果存在对应会话,则表示用户已登录,返回用户请求的资源

  13. 当用户第二次访问相同应用服务时,应用服务会再次验证会话Cookie,如果存在对应会话,则表示用户已登录,返回用户请求的资源

    GET https://app.example.com/resourceCookie: JSESSIONID=ABC1234567
  14. 用户通过浏览器访问被保护的另一个应用(暂且称之为 应用服务2)

    GET https://app2.example.com/
  15. 应用服务2上的CAS客户端检测到用户需要进行身份认证时,携应用返回302响应状态码,指示浏览器重定向到CAS服务器。

    关键响应头

    location: https://cas.example.com/cas/login?service=https%3A%2F%2Fapp2.example.com%2F
  16. 浏览器根据302响应状态码及响应头location指示,携CASTGCCookie自动重定向访问CAS服务器。

    GET https://cas.example.com/cas/login?service=https%3A%2F%2Fapp2.example.com%2FCookie: CASTGC=TGT-2345678
  17. CAS服务器根据CASTGC检测是否已存在SSO会话,发现已存在对应会话(即无需CAS登录),签发一个ST, 返回302响应状态码,及location请求头,提示浏览器重定向访问应用服务。

    关键响应头

    Location: https://app2.example.com/?ticket=ST-345678
  18. 浏览器根据302响应状态码及响应头location指示,自动重定向访问 应用服务2。

    GET https://app2.example.com/?ticket=ST-345678

  1. 应用服务2收到请求后,请求CAS服务器服务验证接口,验证ST

    GET https://cas.example.com/serviceValidate?service=https%3A%2F%2Fapp2.example.com%2F&ticket=ST-345678
  2. CAS服务器对ST进行验证,生成XML响应报文,返回给应用服务,该XML响应报文包含是包含是否验证成功、被认证的用户信息、可选属性。

  3. 应用服务2收到响应报文后,可根据CAS服务器验证结果,为当前用户生成会话,返回302响应状态码,Set-Cookielocation响应头,提示浏览器存储会话Cookie,并再次通过重定向访问应用服务2。

    关键响应头:

    Set-Cookie: MOD_AUTH_CAS_S=XYZ1234567Location: https://app.example.com/

    注意:上述Location中的URL,没有携带ticket参数,避免长时间将ST暴露在浏览器地址栏中

  4. 用户浏览器收到响应后,根据提示重定向访问应用服务2

    GET https://app2.example.com/Cookie: MOD_AUTH_CAS_S=XYZ1234567
  5. 应用服务2收到上述请求后,验证会话Cookie,如果存在对应会话,则表示用户已登录,返回用户请求的资源

CAS单点登出(SLO,Single Logout )

单点登出(注销登录),意味着除了让CAS服务器自身SSO会话失效,还将使客户端应用会话失效,如果CAS客户端支持注销协议的话。

只要TGT过期,就会启动注销协议。

使用警告!

默认情况下,启用单点登出。

当CAS会话结束时,它会通知每个应用服务SSO会话不再有效,依赖方需要使自己的会话无效。记住,提交给每个CAS保护应用服务的回调仅是一个通知,没有别的了。应用程序需要拦截该通知,并通过特定端点手动或更常见的是通过支持SLO的CAS客户端类库正确销毁用户身份验证会话。

还要注意,由于SLO是一个全局事件,因此默认情况下,将联系具有CAS身份验证记录的所有应用程序,如果这些应用程序彼此不同,则可能会对用户体验造成负面影响。例如,如果用户已登录门户应用程序和电子邮件应用程序,则通过SLO注销其中一个应用程序也会破坏另一个的用户会话,如果应用程序没有仔细管理其会话和用户活动,这可能意味着数据丢失。

流程如下:

通过访问CAS服务器logoutAPI(如下),可以注销CAS登录。

https://cas.example.com/cas/logout

如果希望注销登录后,跳转到应用服务登录页,需要添加service参数,并设置跳转目标URL,如下:

https://wcas.sit.sf-express.com/cas/logout?service=https%3A%2F%2Fcas.example.com%2Fcas%2Flogin%3F

参考连接

https://apereo.github.io/cas/6.6.x/planning/Architecture.html

https://apereo.github.io/cas/6.6.x/protocol/CAS-Protocol.html

https://apereo.github.io/cas/6.6.x/protocol/CAS-Protocol-Specification.html

https://cloud.tencent.com/developer/article/2141095

https://apereo.github.io/cas/6.6.x/installation/Logout-Single-Signout.html

关键词: