CAS协议是一种广泛使用的单点登录（Single Sign-On, SSO）协议，它在互联网和企业内部网络环境中提供了便捷的身份验证机制。CAS协议的主要目标是让用户只需要一次登录，就能访问多个相互信任的服务，而无需多次输入凭证。本文将深入解析CAS协议的核心概念、流程和不同版本的特点。
CAS1.0与CAS2.0的区别在于：
1. CAS1.0（基础模式）主要适用于所有参与SSO的应用都是Web应用，且彼此独立，没有复杂集成需求的场景。在这个模式下，用户通过CAS Server认证后，可以访问所有参与SSO的Web应用。
2. CAS2.0（代理模式）则扩展了CAS1.0的功能，允许参与SSO的包含非Web应用，并处理了应用之间的集成问题。非Web应用不能直接使用Cookie，因此CAS2.0引入了代理服务（Proxy Service）来处理非Web应用的认证。
CAS协议的关键组件包括：
1. **术语**：Client（客户端）、Server（服务端）、Service（服务）、Proxy（代理）、Target（目标服务）。
2. **接口**：/login（登录）、/logout（登出）、/validate（验证）、/serviceValidate（服务验证）、/proxyValidate（代理验证）、/proxy（代理服务接口）。
3. **票据**：
- **Ticket Granting Ticket (TGT)**：用户成功登录CAS Server后获得的票据，用于证明用户已通过认证。TGT通常包含了用户的认证信息和一个与用户浏览器相关的Cookie值。
- **Service Ticket (ST)**：当用户尝试访问特定服务时，由CAS Server签发的临时访问令牌。服务端通过ST向CAS Server验证用户身份，如果验证成功，允许用户访问服务。
- **Proxy Ticket Granting Ticket (PGT)**：在CAS2.0中，当Proxy Service认证成功后，CAS Server会返回PGT，用于代理服务为其他Target Service申请PT。
- **PGTIOU（PGT Identifier Of Unique）**：作为PGT的安全补充，用于确保PGT在传输过程中的安全性。
- **Proxy Ticket (PT)**：用户通过Proxy Service获取的票据，用于访问Target Service。Target Service验证PT成功后，允许用户访问。
CAS协议的工作流程大致如下：
1. 用户首次访问受CAS保护的服务时，会被重定向到CAS Server进行身份验证。
2. 用户在CAS Server上成功登录后，CAS Server会签发一个TGT并存储在服务器端，同时将Cookie发送给用户浏览器。
3. 当用户尝试访问服务时，服务端检查用户是否持有有效的ST。如果没有，服务端会将用户重定向到CAS Server的/serviceValidate接口，并附带服务URL。
4. 用户浏览器携带TGT到达CAS Server，服务器验证TGT有效后，签发一个ST并返回给用户，同时销毁旧的TGT。
5. 用户将ST提交给服务端，服务端拿着ST去CAS Server验证，验证通过后，允许用户访问资源。
在CAS2.0中，如果Target Service是非Web应用，用户可以通过Proxy Service间接访问。Proxy Service使用PGT和PGTIOU向CAS Server申请PT，然后用户使用PT访问Target Service。
CAS协议提供了一种安全、高效的身份验证框架，支持多种应用场景，特别是那些需要跨平台、跨应用的单点登录需求。其不同版本的特性满足了不同环境下的认证需求，从而在现代网络环境中广泛应用。
我的内容管理
展开
