基于CAS协议的SSO单点登录-深度剖析
基于CAS协议的SSO单点登录-深度剖析
单点登录（SSO）是现代应用系统中常见的身份验证机制，它允许用户只需登录一次就可以访问多个相关联的应用程序。本文将深入剖析基于CAS协议的SSO实现原理，帮助读者理解其核心技术细节。
一、什么是单点登录？
什么是单点登录？就是用户只需登录一次，就可以访问多个应用。比如：支付宝登陆后，就能访问地铁缴费系统、生活缴费系统等。（Single Sign-On），简称：SSO。
二、单点登录基本实现是怎样的？
一般而言，SSO的实现原理如下图所示：
其主要流程如下：
- 用户首次访问需要登录的应用程序。
- 应用程序将用户引导到身份提供者（IdP），用户在这里输入用户名和密码进行登录。
- IdP验证用户后，会发放一个令牌（Token），包含用户信息。
- 用户被引导回应用程序，并将令牌发送给它，应用程序用此令牌确认用户身份并允许访问。
- 如果用户访问其他需要登录的应用，应用程序也会使用相同的令牌进行身份验证。
这样，用户只需登录一次，就可以访问多个应用。
三、SSO协议有哪些？ 优劣势对比分析？
SSO可通过多种身份验证协议和技术来实现。比如：
- Custom Protocol：
自定义协议通常是根据特定需求设计的，灵活性高，但缺乏标准化，可能导致互操作性问题。 - CAS (Central Authentication Service)：
CAS 是一个开源的 SSO 协议，允许用户通过一个中央服务进行身份验证。它的工作原理是通过重定向用户到认证服务器，成功后返回一个票据，用户使用该票据访问其他服务。 - OAuth：
OAuth 是一种授权协议，允许第三方应用程序访问用户在某一服务上的资源，而无需直接分享用户的凭据。OAuth 2.0 可用于实现 SSO，但主要关注授权而非认证。 - OpenID：
OpenID 是一种去中心化的认证协议，允许用户使用一个身份在多个网站上登录。用户在 OpenID 提供者处认证后，可以访问其他依赖该身份的服务。 - RESTful API：
RESTful API 本身不是 SSO 协议，但可以与 OAuth 或其他认证机制结合使用，以实现基于 API 的 SSO。 - SAML 1.1 / SAML 2.0：
SAML（安全断言标记语言）是用于单点登录的标准协议。SAML 2.0 是对 1.1 的增强，支持更多的功能和更好的安全性。它通过交换安全断言来进行身份验证，通常用于企业级应用和服务提供商。
主流的大厂主要用基于OAuth做单点登录，有一些教育机构使用CAS来做单点。考虑到本文内容有限，且CAS是开源的，方便拓展，所以本文重点梳理基于CAS协议的SSO流程。
四、CAS原理详细流程是怎样的？
CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法。
1、CAS相关概念
首先，来了解一下CAS的相关概念：
- AS：Authentication Service：认证服务，发放TGT
- KDC：Key Distribution Center：密钥发放中心
- TGS：Ticket-Granting Service：票据授权服务，索取TGT，发放ST
- TGC：ticket-granting cookie：授权的票据证明，由CAS Server通过SSL方式发送给终端用户。该值存在Cookie中，根据TGC可以找到TGT。
- TGT：Ticket Granting tieckt：俗称大令牌，或者票根，由KDC和AS发放，获取该票据后，可直接申请其他服务票据ST，不需要提供身份认证信息
- ST：Service Ticket：服务票据，由KDC的TGS发放，ST是访问server内部的令牌
2、CAS认证流程
下面是 CAS 最基本的协议过程：
主要流程如下：
- 访问服务：由于CAS client和WEB应用部署在一起，当用户访问WEB应用时，CAS client就会处理请求。
- 定向认证：CAS client客户端校验HTTP请求中是否包含ST和TGT，如果没有则会重定向到CAS server地址进行用户认证。
- 用户认证：用户通过浏览器填写用户信息，提交给CAS Server认证。
- 发放票据：CAS Server校验过用户信息后，为CAS client发放ST，并在浏览器cookie中（5）设置TGC，下次访问CAS Server时会根据TGC和TGT验证，判断是否已经登录。
- 验证票据：CAS Client拿到ST后，再次请求CAS Server验证ST合法性，验证通过后允许客户端访问。
- 传输用户信息：CAS Server校验过ST后，传输用户信息给CAS client
CAS请求认证时序图如下：
其时序流程如下：
（1）用户认证
用户登录：用户首次访问SSO系统时，输入用户名和密码进行认证。
生成TGT：成功认证后，认证服务器生成一个TGT，并将其存储在服务器上。同时，TGT会被加密并发送给用户的浏览器，通常以Cookie形式存储（即TGC，就是加密后的TGT）。
（2）请求服务
用户访问服务：用户请求访问某个具体的服务（如：某页面时）。
发送TGT：用户的浏览器将TGC发送到认证服务器（一般是CAS Server端），以请求服务票据（ST）。
（3）生成ST
验证TGT：认证服务器（一般是CAS Server端）接收到TGC后，解密并验证TGT的有效性（TGT的存活周期默认为 120 分钟）。
生成ST：如果TGT有效，认证服务器会生成一个ST（默认5分钟），表示用户可以访问请求的服务。ST也会被加密，并返回给用户的浏览器。
（4）访问服务
发送ST：用户的浏览器将加密后的ST发送到目标服务进行验证（应用程序）。
验证ST：目标服务接收到ST后，向认证服务器（一般是CAS Server端）验证ST的有效性（ST是基于TGT
进行验证的）。 - 如果ST有效，目标服务可直接访问。但CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会清除服务端缓存中的该Ticket。
- 如果ST无效，进入（3）步骤，验证TGT，生成新的ST。如果TGT依旧无法验证通过，则进入登录页，输入用户名、密码再次验证。
（5）登出
用户登出时，注销操作通常会使TGT失效，从而影响所有基于该TGT的ST，需要用户输入用户名、密码重新验证。
3、疑问：CAS为何要有ST票据？只有TGT验证不行么？
到这里，是不是跟我有同样的疑问，既然CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会清除服务端缓存中的该Ticket。那仅仅用TGC验证不就好了么？
究竟，为何还单独设计ST票据呢？主要原因有如下几点原因：
- 分离权限
- 不同服务的访问控制：TGT通常用于获取ST，而ST则是针对特定服务的票据。这样的分离使得每个服务可以根据自己的需求对访问进行更细粒度的控制。
- 减少TGT的风险
- 限制TGT的使用范围：TGT具有较长的有效期，如果直接使用TGT访问每个服务，可能会增加被盗用的风险。ST在使用后立即失效，从而降低了风险。
- 支持多服务环境
- 多种服务的访问：在SSO环境中，用户可能需要访问多个服务。每个服务都可以使用ST进行独立验证，不需要每次都验证TGT，这样可以提高效率。
- 强制重新认证
- 安全策略：使用ST允许系统实施安全策略，例如限制ST的有效期或强制用户在一定时间后重新认证。TGT通常具有较长的有效期，直接使用可能会导致安全隐患。
- 简化服务端的验证
- 性能优化：使用ST可以简化目标服务的验证过程，因为它只需要验证一个短期有效的票据，而不必每次都去检查TGT的有效性。
- 避免重放攻击
- 一次性使用：ST的设计确保每个ST只能使用一次，防止重放攻击。这意味着，即使攻击者获取了ST，也无法再次使用它。
五、CAS 安全性是如何保证的？
CAS 的安全性主要依赖于 SSL ，使用的是 secure cookie 。
1、TGC安全性
对于一个 CAS 用户来说，最重要是要保护它的 TGC ，如果 TGC 不慎被 CAS Server 以外的实体获得， Hacker 能够找到该 TGC ，然后冒充 CAS 用户访问所有授权资源。
从上述流程可以看出， TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保 CAS 的安全性。
TGT 的存活周期默认为 120 分钟。
2、ST安全性
ST （ Service Ticket ）是通过 Http 传送的，因此网络中的其他人可以 Sniffer 到其他人的 Ticket 。 CAS 通过以下几方面来使 ST 变得更加安全（事实上都是可以配置的）：
- （1）ST 只能使用一次
CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会清除服务端缓存中的该Ticket，从而可以确保一个 Service Ticket 不被使用两次，防止未授权的重放攻击。 - （2）ST 在一段时间内失效
CAS 规定 ST 只能存活一定的时间，然后 CAS Server 会让它失效。
默认有效时间为 5 分钟。 - （3）ST 是基于随机数生成的
ST 必须足够随机，如果 ST 生成规则被猜出， Hacker 就等于绕过 CAS 认证，直接访问 对应的服务。