CAS单点登录原理与部署配置详解

"CAS（Central Authentication Service）是一种广泛使用的开源单点登录（Single Sign-On, SSO）协议。本文档将详细介绍如何部署CAS服务器以及相关的验证流程。" 在单点登录系统中，CAS扮演着核心角色，它允许用户通过一次认证就可以访问多个应用，而无需反复输入凭证。这里我们探讨的是在不同Web应用中集成CAS客户端的部署规则。 首先，有两个Web应用test1和test2，它们都在同一个域名下运行，分别是www.zhuowei.com的8081和8082端口。同时，有一个专门的CAS服务器（Cas-server）在80端口上运行，用于处理所有认证请求。 **主要组件和流程：** 1. **Ticket Granting Ticket (TGT)**：这是CAS服务器生成的一种授权令牌，代表用户的认证信息。当用户首次访问应用时，如果没有TGT，会被引导至CAS服务器进行登录。 2. **Ticket Granting Cookie (TGC)**：成功登录后，CAS服务器将TGT存储在一个安全的cookie（TGC）中，发送给用户浏览器。这个cookie用于后续的认证过程。 3. **Service Ticket (ST)**：基于TGT，CAS服务器会生成一个ST，这是一个随机加密的字符串，用于特定服务的临时授权。ST在每个服务请求时使用，且只能使用一次。 **认证流程：** 1. 用户尝试访问test1，由于没有TGC，被重定向到CAS服务器的登录页面。 2. 用户输入凭证，服务器验证通过后，生成TGT，用TGT生成ST，并将TGT存储在TGC中，然后将TGC和ST返回给浏览器，同时重定向回test1。 3. test1收到ST后，将其与本地session中的TGT进行对比。若无匹配的TGT，就向CAS服务器发送ST以验证。服务器验证ST有效后，销毁ST，返回认证通过的标识，test1接收后将TGT存入自身session，允许访问。 4. 用户再次访问test1时，TGC携带在请求中，test1验证TGT与session中的匹配，通过后允许访问。 5. 如果用户访问test2，虽然有TGC但无ST，test2同样会向CAS服务器请求ST，服务器验证TGT后，生成新的ST，返回给test2。test2验证后将TGT存入其session，完成认证。 通过这种方式，CAS确保了用户只需一次登录，就能在所有集成的应用之间无缝切换，提高了用户体验并增强了安全性。对于大型企业或组织来说，CAS部署是实现高效、统一的认证管理的关键步骤。