网络基础 CAS协议学习总结

架构介绍

CAS Architecture Diagram

系统组件

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), 存储在 TGC cookie中，为SSO(Single Sign On，单点登录，)会话的Key，代表某个用户的某个SSO会话。
TGC(Ticket Granted Cookie)，以TGT为值的Cookie
ST (Service Ticket，服务票证), 作为GET URL请求参数传输，表示由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流程图

CAS Web flow diagram

过程详述

用户通过浏览器访问被保护的应用(暂且称之为应用服务)
```
GET https://app.example.com/
```
应用服务上的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编码后的地址)
浏览器根据302响应状态码及响应头location指示，自动重定向访问CAS服务器。
```
GET https://cas.example.com/cas/login?service=https%3A%2F%2Fapp.example.com%2F
```
CAS服务器未检测到SSO会话，向用户返回CAS登录表单页面。

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

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

CAS服务器接收到用户名和密码后，对用户进行验证（可使用CAS服务器默认的验证，也可以自定义实现验证方法），如果验证通过，则创建SSO会话，签发一个ST(作为location请求中URL参数传输) ，返回302响应状态码，及location请求头，提示浏览器重定向访问应用服务。

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

注意，CASTGC也可能被命名为其它类似名称，比如 CASTGC-D，如果有对CAS服务器进行相关改造的话。
浏览器根据302响应状态码及响应头location指示，自动重定向访问应用服务。
```
GET https://app.example.com/?ticket=ST-12345678
```
应用服务收到请求后，请求CAS服务器服务验证接口，验证ST

注意：每个ST只能用一次，且存在有效期，这就是为啥需要二次访问CAS服务器进行验证的原因。
```
GET https://cas.example.com/serviceValidate?service=https%3A%2F%2Fapp.example.com%2F&ticket=ST-12345678
```
CAS服务器对ST进行验证，生成XML响应报文，返回给应用服务，该XML响应报文包含是包含是否验证成功、被认证的用户信息、可选属性。
应用服务收到响应报文后，可根据CAS服务器验证结果，为当前用户生成会话，返回302响应状态码，Set-Cookie及location响应头，提示浏览器存储会话Cookie，并再次通过重定向访问应用服务。

关键响应头：
```
Set-Cookie: JSESSIONID=ABC1234567
Location: https://app.example.com/
```
注意：上述Location中的URL，没有携带ticket参数，避免长时间将ST暴露在浏览器地址栏中
用户浏览器收到响应后，根据提示重定向访问应用服务
```
GET https://app.example.com/
Cookie: JSESSIONID=ABC1234567
```
应用服务收到上述请求后，验证会话Cookie，如果存在对应会话，则表示用户已登录，返回用户请求的资源
当用户第二次访问相同应用服务时，应用服务会再次验证会话Cookie，如果存在对应会话，则表示用户已登录，返回用户请求的资源
```
GET https://app.example.com/resource
Cookie: JSESSIONID=ABC1234567
```
用户通过浏览器访问被保护的另一个应用(暂且称之为应用服务2)
```
GET https://app2.example.com/
```
应用服务2上的CAS客户端检测到用户需要进行身份认证时，携应用返回302响应状态码，指示浏览器重定向到CAS服务器。

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

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

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

GET https://cas.example.com/serviceValidate?service=https%3A%2F%2Fapp2.example.com%2F&ticket=ST-345678

CAS服务器对ST进行验证，生成XML响应报文，返回给应用服务，该XML响应报文包含是包含是否验证成功、被认证的用户信息、可选属性。
应用服务2收到响应报文后，可根据CAS服务器验证结果，为当前用户生成会话，返回302响应状态码，Set-Cookie及location响应头，提示浏览器存储会话Cookie，并再次通过重定向访问应用服务2。

关键响应头：
```
Set-Cookie: MOD_AUTH_CAS_S=XYZ1234567
Location: https://app.example.com/
```
注意：上述Location中的URL，没有携带ticket参数，避免长时间将ST暴露在浏览器地址栏中
用户浏览器收到响应后，根据提示重定向访问应用服务2
```
GET https://app2.example.com/
Cookie: MOD_AUTH_CAS_S=XYZ1234567
```
应用服务2收到上述请求后，验证会话Cookie，如果存在对应会话，则表示用户已登录，返回用户请求的资源

CAS单点登出(SLO,Single Logout )

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

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

使用警告！

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

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

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

流程如下：

通过访问CAS服务器logout API(如下)，可以注销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

原文链接：https://www.cnblogs.com/shouke/p/17281670.html

本站文章如无特殊说明，均为本站原创，如若转载，请注明出处：网络基础 CAS协议学习总结 - Python技术站