1. 会话与Cookie
HTTP是无状态协议，客户端与服务端之间的每次通信都是独立的，而会话机制可以让服务端鉴别每次通讯过程中的客户端是否是同一个，从而保证业务的关联性。 Session是服务器使用一种类似于散列表的结构，用来保存用户会话所需要的信息.Cookie作为浏览器缓存，存储Session ID以达到会话跟踪的目的。
会话与Cookie缓存
2. CAS介绍
2.1 CAS简介
SSO 单点登录，是企业为了解决在相互信任的系统上实现一次登录的解决方案。SSO将一个企业内部所有域中的用户登录和用户帐号管理集中到一起，SSO的好处显而易见：
减少用户在不同系统中登录耗费的时间，减少用户登录出错的可能性；
实现安全的同时避免了处理和保存多套系统用户的认证信息；
减少了系统管理员增加、删除用户和修改用户权限的时间；
增加了安全性：系统管理员有了更好的方法管理用户，包括可以通过直接禁止和删除用户来取消该用户对所有系统资源的访问权限。
CAS是SSO解决方案里面比较成熟的架构，是耶鲁大学发起的一个开源架构，其旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。CAS 具有以下特点：
开源的企业级单点登录解决方案。
CAS Server 为需要独立部署的 Web 应用。
CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
下图是 CAS 最基本的协议过程：
CAS协议过程
访问服务：SSO客户端发送请求访问应用系统提供的服务资源。
重定向认证：SSO客户端会重定向用户请求到SSO服务器。
用户验证：用户身份认证。
生成票据：SSO服务器会产生一个随机的Service Ticket。
验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后，允许客户端访问服务。
传输用户信息：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。
2.2 CAS架构
CAS架构
CAS架构包括两部分：CAS Server和CAS Client。
CAS Server 需要独立部署，主要负责对用户的认证工作；
CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。
2.3 CAS基本流程
CAS基于Cookie单点登录的实现流程
用户在单点登录服务器的登录页面中，输入用户名和密码。
然后单点登录服务器会对用户名和密码进行认证。认证本身并不是单点登录服务器的功能，因此，通常会引入某种认证机制。认证机制可以有很多种，例如自己写一个认证程序，或者使用一些标准的认证方法，例如LDAP或者数据库等等。在大多数情况下，会使用LDAP进行认证。这是因为LDAP在处理用户登录方面，有很多独特的优势，这在本文的后面还会比较详细地进行介绍。
认证通过之后，单点登录服务器会和应用程序进行一个比较复杂的交互，这通常是某种授权机制。CAS使用的是所谓的Ticket。具体这点后面还会介绍。
授权完成后，CAS把页面重定向，回到Web应用。Web应用此时就完成了成功的登录（当然这也是单点登录的客户端，根据返回的Ticket信息进行判断成功的）。
然后单点登录服务器会在客户端创建一个Cookie。注意，是在用户的客户端，而不是服务端创建一个Cookie。这个Cookie是一个加密的Cookie，其中保存了用户登录的信息。
如果用户此时希望进入其他Web应用程序，则安装在这些应用程序中的单点登录客户端，首先仍然会重定向到CAS服务器。不过此时CAS服务器不再要求用户输入用户名和密码，而是首先自动寻找Cookie，根据Cookie中保存的信息，进行登录。登录之后，CAS重定向回到用户的应用程序。
2.4 CAS应用交互详解
以下是CAS应用之间交互过程的详细时序图与说明。
CAS基于Cookie单点登录的实现流程
浏览器与APP01服务端
浏览器第一次访问受保护的APP01服务端，由于未经授权而被拦截并重定向到CAS服务端。
浏览器第一次与CAS服务端通讯，鉴权成功后由CAS服务端创建全局会话SSO会话，生成全局会话标识TGT并存在浏览器Cookie中。
浏览器重定向到APP01，重写URL地址带上全局会话标识TGT。
APP01拿到全局会话标识TGT后向CAS服务端请求校验，若校验成功，则APP01会获取到已经登录的用户信息。
APP01创建局部会话Session，并将SessionID存储到浏览器Cookie中。
浏览器与APP01建立会话。
作者：garyond
链接：https://www.jianshu.com/p/e30290347521