CAS应用流程简介

最新推荐文章于 2025-06-18 15:24:31 发布

最新推荐文章于 2025-06-18 15:24:31 发布 · 209 阅读

文章标签：

#应用服务器 #Web

Java 专栏收录该内容

5 篇文章

订阅专栏

本文详细介绍了中央认证服务（CAS）作为一种单点登录协议的工作原理和应用场景。包括用户通过URL访问应用时CAS过滤器如何检测登录状态并重定向至CAS服务器进行认证的过程，以及认证成功后如何通过服务票据（ST）和Ticket Granting Cookie（TGC）实现后续的认证流程。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Wiki上的定义：
The Central Authentication Service (CAS) is a single sign-on protocol for the web.

应用场景：单点登陆做为认证服务器

流程图
[img]/upload/attachment/61491/a76cb26f-147b-34e1-ad90-55c8d8d2371f.gif[/img]

具体步骤如下：
1. 用户通过URL访问Application，CAS Filter（需要在Application中配置）检测到用户没有登陆，通过一个https的URL来到CAS Server的登陆界面，此时URL中以service为参数名保存了之前尝试访问的url地址，如https://casserver:8443/server?service=http://localhost:myapp....；

2. 用户输入loginID和password， CASServer对用户进行认证，如果认证失败，Application就收不到该请求；

3. 如果认证成功，会将用户请求redirect到目标Application，并在请求的URL后边加上?ticket=......,如上图中的http://localhost//myapp?ticket...，这个ticket为ST（service ticket），与这次请求的service进行绑定;同时CAS会创建一个保存在内存中的Cookie----Ticket Granting Cookie（与Kerberos TGT一样），也可以认为是TGT，用于重复认证：如果该用户再次访问某个Application，TGT如果已经存在，就不需要重新登陆；

4. Application收到了来自用户的带有ST的请求，会将该ST和service name作为参数发送到CAS指定的一个validate的URL处（该URL为安全连接，https），如上图的第6步，https://localhost/cas/validate?ticket...；CAS会validate这个ST是否合法，并且与service是否匹配，如果验证通过，就允许用户调用该service，并将该用户的用户名返回给Application。

在单点登陆中所集成的各个Web Application子系统统一使用CAS进行认证，使子系统与认证这一块完全分离，只需要对Ticket进行解析获取相应的用户就行了，并且可以实现跨域访问，使用Cookie不能跨域。