CAS实现SSO单点登录原理
1.      CAS简介
1.1.  What is CAS？
CAS （Central Authentication Service ）是Yale ⼤学发起的⼀个企业级的、开源的项⽬，旨在为Web 应⽤系统提供⼀种可靠的单点登录解决⽅法（属于Web SSO ）。
CAS 开始于2001 年，并在2004 年12 ⽉正式成为JA-SIG 的⼀个项⽬。
1.2.  主要特性
1、  开源的、多协议的SSO 解决⽅案；Protocols ：Custom Protocol 、CAS 、OAuth 、OpenID 、RESTful
API 、SAML1.1 、SAML2.0 等。
2、  ⽀持多种认证机制：Active Directory 、JAAS 、JDBC 、LDAP 、X.509 Certificates 等；
3、  安全策略：使⽤票据（Ticket ）来实现⽀持的认证协议；
4、  ⽀持授权：可以决定哪些服务可以请求和验证服务票据（Service Ticket ）；
5、  提供⾼可⽤性：通过把认证过的状态数据存储在TicketRegistry 组件中，这些组件有很多⽀持分布式环境的实现，
如：BerkleyDB 、Default 、EhcacheTicketRegistry 、JDBCTicketRegistry 、JBOSS
TreeCache 、JpaTicketRegistry 、MemcacheTicketRegistry 等；
6、  ⽀持多种客户端：Java 、.Net 、PHP 、Perl 、Apache, uPortal 等。
2.      SSO单点登录原理
本⽂内容主要针对Web SSO 。
2.1.  什么是SSO
单点登录（Single Sign-On , 简称SSO ）是⽬前⽐较流⾏的服务于企业业务整合的解决⽅案之⼀，SSO 使得在多个应⽤系统中，⽤户只需要登录⼀次就可以访问所有相互信任的应⽤系统。
2.2.  SSO原理
2.2.1.    SSO体系中的⾓⾊
⼀般SSO 体系主要⾓⾊有三种：
1、 User （多个）
2、 Web 应⽤（多个）
3、 SSO 认证中⼼（ 1 个）
2.2.2.    SSO实现模式的原则
SSO 实现模式⼀般包括以下三个原则：
1、  所有的认证登录都在SSO 认证中⼼进⾏；
2、  SSO 认证中⼼通过⼀些⽅法来告诉Web 应⽤当前访问⽤户究竟是不是已通过认证的⽤户；
3、  SSO 认证中⼼和所有的Web 应⽤建⽴⼀种信任关系，也就是说web 应⽤必须信任认证中⼼。（单点信任）
2.2.
3.    SSO主要实现⽅式
SSO 的主要实现⽅式有：
1、  共享cookies
基于共享同域的cookie 是Web 刚开始阶段时使⽤的⼀种⽅式，它利⽤浏览同域名之间⾃动传递cookies 机制，实现两个域名之间系统令牌传递问题；另外，关于跨域问题，虽然cookies本⾝不跨域，但可以利⽤它实现跨域的SSO 。如：代理、暴露SSO 令牌值等。
缺点：不灵活⽽且有不少安全隐患，已经被抛弃。
2、  Broker-based( 基于经纪⼈)
这种技术的特点就是，有⼀个集中的认证和⽤户帐号管理的服务器。经纪⼈给被⽤于进⼀步请求的电⼦⾝份存取。中央数据库的使⽤减少了管理的代价，并为认证提供⼀个公共和独⽴的"第三⽅" 。例如Kerberos 、Sesame 、IBM KryptoKnight （凭证库思
想) 等。Kerberos是由⿇省理⼯⼤学发明的安全认证服务，已经被UNIX 和Windows 作为默认的安全认证服务集成进操作系统。
3、  Agent-based （基于代理⼈）
在这种解决⽅案中，有⼀个⾃动地为不同的应⽤程序认证⽤户⾝份的代理程序。这个代理程序需要设计有不同的功能。⽐如，它可以使⽤⼝令表或加密密钥来⾃动地将认证的负担从⽤户移开。代理⼈被放在服务器上⾯，在服务器的认证系统和客户端认证⽅法之间充当⼀个" 翻译"。例如SSH 等。
4、  Token-based
例如SecureID,WebID ，现在被⼴泛使⽤的⼝令认证，⽐如FTP 、邮件服务器的登录认证，这是⼀种简单易⽤的⽅式，实现⼀个⼝令在多种应⽤当中使⽤。
5、  基于⽹关
6、  基于SAML
SAML(Security Assertion Markup Language ，安全断⾔标记语⾔）的出现⼤⼤简化了SSO ，并被OASIS 批准为SSO 的执⾏标
准 。开源组织 OpenSAML 实现了 SAML 规范。
3.      CAS的基本原理
3.1.  结构体系
从结构体系看，CAS 包括两部分：CAS Server 和CAS Client 。
3.1.1.    CAS Server
CAS Server 负责完成对⽤户的认证⼯作, 需要独⽴部署, CAS Server 会处理⽤户名/ 密码等凭证(Credentials) 。
3.1.2.    CAS Client
负责处理对客户端受保护资源的访问请求，需要对请求⽅进⾏⾝份认证时，重定向到CAS Server 进⾏认证。（原则上，客户端应⽤不再接受任何的⽤户名密码等Credentials ）。
CAS Client 与受保护的客户端应⽤部署在⼀起，以Filter ⽅式保护受保护的资源。
3.2.  CAS原理和协议
3.2.1.    基础模式
基础模式SSO 访问流程主要有以下步骤：
1. 访问服务：SSO 客户端发送请求访问应⽤系统提供的服务资源。
2. 定向认证：SSO 客户端会重定向⽤户请求到SSO 服务器。
3. ⽤户认证：⽤户⾝份认证。
4. 发放票据：SSO 服务器会产⽣⼀个随机的Service Ticket 。
5. 验证票据：SSO 服务器验证票据Service Ticket 的合法性，验证通过后，允许客户端访问服务。
6. 传输⽤户信息：SSO 服务器验证票据通过后，传输⽤户认证结果信息给客户端。
下⾯是 CAS 最基本的协议过程：
基础协议图
如上图：CAS Client 与受保护的客户端应⽤部署在⼀起，以Filter ⽅式保护Web 应⽤的受保护资源，过滤从客户端过来的每⼀个Web 请求，同时，CAS Client 会分析HTTP 请求中是否包含请求Service Ticket( ST 上图中的Ticket) ，如果没有，则说明该⽤户是没有经过认证的；于是CAS Client 会重定向
⽤户请求到CAS Server （Step 2 ），并传递Service （要访问的⽬的资源地址）。Step 3 是⽤户认证过程，如果⽤户提供了正确的Credentials ，CAS Server 随机产⽣⼀个相当长度、唯⼀、不可伪造的Service Ticket ，并缓存以待将来验证，并且重定向⽤户到Service 所在地址（附带刚才产⽣的Service Ticket ）, 并为客户端浏览器设置⼀个 Ticket Granted
Cookie （ TGC ）； CAS Client 在拿到 Service 和新产⽣的 Ticket 过后，在 Step 5 和 Step6 中与 CAS Server 进⾏⾝份核实，以确
保 Service Ticket 的合法性。
在该协议中，所有与CAS Server 的交互均采⽤SSL 协议，以确保ST 和TGC 的安全性。协议⼯作过程中会有 2 次重定向的过程。但
是 CAS Client 与 CAS Server 之间进⾏ Ticket 验证的过程对于⽤户是透明的（使⽤ HttpsURLConnection ）。
CAS 请求认证时序图如下：
3.2.1.    CAS 如何实现SSO
当⽤户访问另⼀个应⽤的服务再次被重定向到CAS Server 的时候，CAS Server 会主动获到这个TGC cookie ，然后做下⾯的事情：
1) 如果User 持有TGC 且其还没失效，那么就⾛基础协议图的Step4 ，达到了SSO 的效果；
2) 如果TGC 失效，那么⽤户还是要重新认证( ⾛基础协议图的Step3) 。
3.2.2.    CAS代理模式
该模式形式为⽤户访问App1 ，App1 ⼜依赖于App2 来获取⼀些信息，如：User -->App1 -->App2。
这种情况下，假设App2 也是需要对User 进⾏⾝份验证才能访问，那么，为了不影响⽤户体验（过多的重定向导致User 的IE 窗⼝不停地闪动) ，CAS 引⼊了⼀种Proxy 认证机制，即CAS Client 可以代理⽤户去访问其它Web 应⽤。
代理的前提是需要CAS Client 拥有⽤户的⾝份信息( 类似凭据) 。之前我们提到的TGC 是⽤户持有对⾃⼰⾝份信息的⼀种凭据，这⾥
的PGT 就是CAS Client 端持有的对⽤户⾝份信息的⼀种凭据。凭借TGC ，User 可以免去输⼊密码以获取访问其它服务的Service Ticket ，所以，这⾥凭借PGT ，Web应⽤可以代理⽤户去实现后端的认证，⽽⽆需前端⽤户的参与。
下⾯为代理应⽤（helloService ）获取PGT 的过程：（注：PGTURL ⽤于表⽰⼀个Proxy 服务，是⼀个回调链接；PGT 相当于代理证；PGTIOU 为取代理证的钥匙，⽤来与PGT 做关联关系；）
如上⾯的CAS Proxy 图所⽰， CAS Client 在基础协议之上，在验证 ST 时提供了⼀个额外的PGT URL( ⽽且是 SSL 的⼊⼝ ) 给 CAS Server ，使得 CAS Server 可以通过 PGT URL 提供⼀个 PGT 给 CAS Client 。
CAS Client 拿到了PGT(PGTIOU-85 … ..ti2td) ，就可以通过PGT 向后端Web 应⽤进⾏认证。
下⾯是代理认证和提供服务的过程：
如上图所⽰，Proxy 认证与普通的认证其实差别不⼤，Step1 ，2 与基础模式的Step1,2 ⼏乎⼀样，唯⼀不同的是，Proxy 模式⽤的
是PGT ⽽不是TGC ，是Proxy Ticket （PT ）⽽不是Service Ticket 。
session如何设置和读取3.2.3.    辅助说明
CAS 的SSO 实现⽅式可简化理解为：1 个Cookie 和N 个Session 。CAS Server 创建cookie，在所有应⽤认证时使⽤，各应⽤通过创建各⾃的Session 来标识⽤户是否已登录。
⽤户在⼀个应⽤验证通过后，以后⽤户在同⼀浏览器⾥访问此应⽤时，客户端应⽤中的过滤器会在session ⾥读取到⽤户信息，所以就不会去CAS Server 认证。如果在此浏览器⾥访问别的web 应⽤时，客户端应⽤中的过滤器在session ⾥读取不到⽤户信息，就会去CAS Server 的login 接⼝认证，但这时CAS Server 会读取到浏览器传来的cookie （TGC ），所以CAS Server 不会要求⽤户去登录页⾯登录，只是会根据service 参数⽣成⼀个Ticket ，然后再和web 应⽤做⼀个验证ticket 的交互⽽已。
3.3.  术语解释
CAS 系统中设计了5 中票据：TGC 、ST 、PGT 、PGTIOU 、PT 。
Ø    Ticket-granting cookie(TGC) ：存放⽤户⾝份认证凭证的cookie ，在浏览器和CAS Server 间通讯时使⽤，并且只能基于安全通道传输（Https ），是CAS Server ⽤来明确⽤户⾝份的凭证；
Ø  Service ticket(ST) ：服务票据，服务的惟⼀标识码, 由CAS Server 发出（Http 传送），通过客户端浏览器到达业务服务器端；⼀个特定的服务只能有⼀个惟⼀的ST ；
Ø  Proxy-Granting ticket （PGT ）：由CAS Server 颁发给拥有ST 凭证的服务，PGT 绑定⼀个⽤户的特定服务，使其拥有向CAS Server 申请，获得PT 的能⼒；
Ø  Proxy-Granting Ticket I Owe You （PGTIOU ）: 作⽤是将通过凭证校验时的应答信息由CAS Serv
er 返回给CAS Client ，同时，与该PGTIOU 对应的PGT 将通过回调链接传给Web 应⽤。Web 应⽤负责维护PGTIOU 与PGT 之间映射关系的内容表；
Ø  Proxy Ticket (PT) ：是应⽤程序代理⽤户⾝份对⽬标程序进⾏访问的凭证；
其它说明如下：
Ø  Ticket Granting ticket(TGT) ：票据授权票据，由KDC 的AS 发放。即获取这样⼀张票据后，以后申请各种其他服务票据(ST) 便不必再向KDC 提交⾝份认证信息(Credentials) ；
Ø  Authentication service(AS) --------- 认证⽤服务，索取Credentials ，发放TGT ；
Ø  Ticket-granting service (TGS) --------- 票据授权服务，索取TGT ，发放ST ；
Ø  KDC( Key Distribution Center ) ---------- 密钥发放中⼼；
4.      CAS安全性
CAS 的安全性仅仅依赖于SSL 。使⽤的是secure cookie 。
4.1.  TGC/PGT安全性
对于⼀个CAS ⽤户来说，最重要是要保护它的TGC ，如果TGC 不慎被CAS Server 以外的实体获得，Hacker 能够到该TGC ，然后冒充CAS ⽤户访问所有授权资源。PGT 的⾓⾊跟TGC 是⼀样的。
从基础模式可以看出，TGC 是CAS Server 通过SSL ⽅式发送给终端⽤户，因此，要截取TGC 难度⾮常⼤，从⽽确保CAS 的安全性。
TGT 的存活周期默认为120 分钟。
4.2.  ST/PT安全性
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 认证，直接访问对应的服务。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。