CAS的ticket是啥？
前言
昨天我舍友用Python自动登录遇到了一个问题，问我看我知道session的ticket是啥？然后我（ticket是啥？我上计算机网络的时候咋没听过）
于是今天我了解了一下这个ticket。涨知识。在此之前我只知道登录验证好像是和cookie、session、token相关，ticket还没了解过。
今天看了看相关资料，了解原来ticket是解决多套系统并存的环境下，用户只需要一次登录就可以访问其他授权的系统的一种解决方案。
下面我具体介绍ticket的内容
文章目录
- CAS的ticket是啥？
- 前言
- 笔记
- 代理登录、token、ticket
- CAS介绍
- CAS-开源单点登录系统-实践
- CAS总结之Ticket篇
- 总结
笔记
代理登录、token、ticket
参考资料：代理登录，token,ticket
SSO，单一登录（single sign-on），意思是指在多套系统并存的环境下，用户只需登录一次即可访问其他授权的系统。
一、企业级SSO
SSO涉及的领域大致上可以分为三种：社会性网站间的SSO、部门SSO、企业级SSO。
社会性网站间的SSO主要涉及的帐号信息开放性问题，能否实施成功主要取决于各大网站帐号管理是否遵循相同的标准协议，如Openid、Passport等。
部门级SSO比较简单，一般涉及的系统不多，由技术人员通过编程方式实现即可，但一旦牵涉系统众多，安全性要求高的情况，就不适用了。
企业级SSO是三者中最复杂的领域，因涉及的系统可能五花八门，这些系统也许是老旧的C/S结构系统、可能是某种大型软件系统（如SAP），还可能是某种非web登录方式（如windows域登录）；其安全性要求也远比前两者高，如要求同享登录有效时间等，因此企业级SSO在技术难度上是最高的，但也因此是IT人员最愿意钻研的领域。而绝大部分国内企业，其内部系统常常因为历史原因导致多套系统缺乏统一规划，缺乏标准而导致整合代价高昂。因此SSO也是许多大中型企业IT部门比较头疼的事情。
本文主要讨论的领域，就是企业级SSO。
二、深入企业级SSO
SSO是一把双刃剑：SSO可以简化用户登录过程，提升用户的登录体验；同时可以降低IT管理员大量账户和密码维护成本；SSO还提供了符合萨班斯法案的密码集中管理工具；但SSO同时也产生了一种安全风险，某一系统用户身份一旦被攻破，则意味着所有参与SSO网络的应用系统也被穿透。因此需要慎重考虑SSO的范围及安全级别的局限性。
**SSO涉及不同层面的需求：**SSO的实质是多套系统能否识别同一用户的身份，并在各套系统间实时同步用户身份信息，以支持各套系统进行用户权限控制。基于这样的原因，一套SSO技术至少应该考虑一下四个层面的需求：
1、 单点登录，多点即可同时登录；
2、 单点注销（退出登录），多点即可同时注销；
3、 单点切换用户，多点即可同时切换；
4、 单点登录过期，多点同时过期。
现实环境中，一个最佳的SSO环境（整合代价最小）应该是：
1、一个用户在不同系统只有一个共同登录名和密码
2、各套应用系统共享一套用户名和密码信息
3、应用系统采用相同的技术架构且域名后缀相同
而一个最坏的SSO环境（整合代价最大）会体现为：
1、一个用户在不同系统有不同的登录名和密码
2、不同的应用系统各自存储了独立的用户名和密码
3、 应用系统采用不同的技术架构且域名后缀不同，甚至只有IP而无域名。
从我们的实操经验来看，能够提供最佳SSO环境的企业，在国内几乎凤毛麟角，这样的企业必须是非常具有IT战略眼光且IT系统选型非常精准，企业历任IT领导间保持了高度的传承共识、IT规划细致到位才可能做到；而最坏或接近最坏的SSO环境却比比皆是。
幸运的是，即便是最坏的SSO环境，也还是有相应的技术解决方案来支持整合的。
这篇文章是2015年11月29号的。
三、SSO的两种架构与三种实现技术
从应用架构层面，SSO主要可以分为集中验证模式和多点验证模式两种不同的架构。
集中验证模式：当应用系统需要登录时，统一交由验证服务器完成登录动作，应用系统不提供登录接入（如登录界面）。
相对与多点验证模式来说，集中验证模式的适用范围更广，而且在SSO服务器中使用的是统一的用户名密码，用户无需关注登录的是哪套系统的账套，所以用户体验更加优秀。由于所有的登录都放在了统一的服务器，所以当集中验证服务器宕机时，所有系统无法正常登录，或丢失SSO的功能，建议以独立服务器作为集中验证服务器，并需要保证登录服务器的稳定性。
多点验证模式：应用系统供各自的登录界面，登录了一套系统后，另外其他系统无需再次登录即可通过身份验证。
在多点验证模式的模式下，所有的登录操作都在应用系统完成，任何一套系统宕机不会对其它系统产生影响，也不会影响正常运行系统间的SSO。但若各套系统的账套不一样的时候，若要用户区分每套系统的用户密码，必定会降低用户的体验，为了解决该问题，多点登录模式最好有统一的用户密码验证的服务（如LDAP身份验证）。另外，多点登录模式相对集中验证模式来说会存在更多的技术限制，详见后面的章节。
从SSO在技术实现的角度，SSO的实现通常有以下三种技术实现途径：代理登录（agent）、令牌环（token）、身份票据（ticket）。
代理登录（agent）：代理登录的原理就是在IE端通过表单提交的方式模拟应用系统的登录操作，实现SSO。
代理登录的优点就是无需对原有系统做任何改造，适用于无法改造的旧系统；
其缺点很明显：
1、稳定性差，一旦登录期间某台服务器无法响应，则该服务器无法单点登录。
2、安全性差，用户名密码通过明文传输。
3、由于登录期间需要监控各个系统的响应，所以不建议大量使用，否则会影响登录的性能。
4、由于IE的安全限制，代理登录必须在同域的情况下运行。
令牌环（token）：通过Cookie共享令牌环的方式传递当前用户信息，实现SSO。（令牌环类似IBM的LTPA Token，IBM系列产品间能实现配置式SSO，就依靠此技术。如IBM Websphere Portal Server与Lotus Domino Server之间的SSO）
令牌环的方式最大好处在于无需统一的验证服务器，是“多点验证模式”的主力实现技术，各个服务器都通过统一的密钥对令牌进行加密解密，所以该方式具有安全性高、稳定性好、性能消耗低等优点；其缺点就是必须保证各台应用服务器同域。
身份票据（ticket）：与令牌环不一样，身份票据是通过URL的方式传递，通过“两次握手”的方式，实现SSO。（如开源的CAS就是这种原理）
身份票据的方式，是适用范围最广的一种SSO实现方式，可以解决跨域等问题，安全性高、稳定性好；其缺点就是必须增加一台验证服务器，保证在高压下验证服务器的稳定运行，性能方面由于每次登录都需要访问验证服务器，所以比令牌环的方式略差一点。
三种技术实现途径的比较
比较项代理登录令牌环身份票据需求实现程度无法实现同时切换用户与会话同时过期全部全部对原系统改造无小量改造小量改造安全性低高高稳定性偏低好好性能开销登录瞬间压力大一点非常小较小适用范围同域，对用户密码不一致的系统，需在登录服务器的用户凭证库保存用户密码映射同域，对不同登录名需增加对用户凭证库的访问所有可改造的系统，对不同登录名需在登录服务器的用户凭证库保存用户映射独立验证服务器需要不需要需要登录模式支持集中验证模式集中验证模式/多点验证模式集中验证模式
CAS介绍
参考资料：百度百科的CAS介绍
CAS是Central Authentication Service的缩写，中央认证服务，一种独立开放指令协议。CAS 是 耶鲁大学（Yale University）发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。
特点：
1、开源的企业级单点登录解决方案。
2、CAS Server 为需要独立部署的 Web 应用。
3、CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
4、CAS属于Apache 2.0许可证，允许代码修改，再发布（作为开源或商业软件）。
原理和协议：
从结构上看，CAS 包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。图1 是 CAS 最基本的协议过程：
CAS的ticket是啥？ CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。用户在第 3 步中输入认证信息，如果登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5，6 步中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。
在该协议中，所有与 CAS 的交互均采用 SSL 协议，确保，ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。
另外，CAS 协议中还提供了 Proxy （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考 CAS 官方网站上的相关文档。
CAS-开源单点登录系统-实践
参考文章：CAS-开源单点登陆系统-实践
一、CAS入门
1、什么是单点登陆？
单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
我们目前的系统存在诸多子系统，而这些子系统是分别部署在不同的服务器中，那么使用传统方式的session是无法解决的，我们需要使用相关的单点登录技术来解决。
CAS的ticket是啥？ 2、什么是cas?
CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。CAS 具有以下特点：
【1】开源的企业级单点登录解决方案。
【2】CAS Server 为需要独立部署的 Web 应用。
【3】CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
SSO单点登录访问流程主要有以下步骤：CAS的ticket是啥？
- 访问服务：SSO客户端发送请求访问应用系统提供的服务资源。
- 定向认证：SSO客户端会重定向用户请求到SSO服务器。
- 用户认证：用户身份认证。
- 发放票据：SSO服务器会产生一个随机的Service Ticket。
- 验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后，允许客户端访问服务。
- 传输用户信息：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。
3、CAS服务器的部署
cas资源地址：https://github.com/apereo/cas
cas的服务器其实就是一个war包。
在cas-server-4.0.0-release\cas-server-4.0.0\modules目录下cas-server-webapp-4.0.0.war 将其改名为cas.war放入tomcat目录下的webapps下。
启动tomcat自动解压war包。浏览器输入http://localhost:8080/cas/login ，可看到登录页面
完成将cas服务器部署到tomcat上CAS的ticket是啥？ 这里有个固定的用户名和密码 casuser /Mellon
登录成功后会跳到登录成功的提示页面
CAS的ticket是啥？ 4、cas服务端的相关配置
1）可以修改tomcat的端口
打开tomcat 目录 conf\server.xml 找到下面的配置
CAS的ticket是啥？ 这里修改成 9100
2） 修改CAS配置文件
修改cas的WEB-INF/cas.properties
server.name=http://localhost:9100
3）去除https认证
CAS默认使用的是HTTPS协议，如果使用HTTPS协议需要SSL安全证书（需向特定的机构申请和购买） 。如果对安全要求不高或是在开发测试阶段，可使用HTTP协议。我们这里讲解通过修改配置，让CAS使用HTTP协议。
后面还有一些操作，我就没复制了。
CAS总结之Ticket篇
参考资料：CAS总结之Ticket篇(转,非常详细，后文还提到一个ppt，非常易懂)
CAS的核心就是其Ticket，及其在Ticket之上的一系列处理操作。CAS的主要票据有TGT、ST、PGT、PGTIOU、PT，其中TGT、ST是CAS1.0协议中就有的票据，PGT、PGTIOU、PT是CAS2.0协议中有的票据。
里面有许多细节，我这里就不展示了。
总结
简单普及一下。
其实简单一想就发现，出乎意料又在情理之中。一家公司如果有多个网站，用户登录一个需要登录一下，这无疑是一件不友好的事情，而且后台管理开销也很大。
我在《后端技术栈科普——springboot一家》中写了关于互联网系统架构的演进的内容。和这个有一定的相关性。
技术就是根据应用场景而成长的。
我在写《JavaScript设计模式》初次笔记的时候说到的设计模式的思想：提高可复用性和维护性。使开发高效，开发成本降低，危险降低。