SSO是什么？
前言
春节前正在维护公司的登录模块，和token，session啥的斗智斗勇了一段时间。不过今天突然发现自己的一个学弟有篇颇为不错的文章。便把它发了出来，希望更多的朋友可以少走弯路。
因为篇幅过长，所以这里把一个系列拆分成多个部分。当前部分暂时定位为：SSO前置概念铺垫篇。后续将有：服务器篇 + 前端/客户端篇
正文
一：SSO体系结构
SSO
SSO英文全称Single Sign On，单点登录。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一。
体系结构
当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录;根据用户提供的登录信息，认证系统进行身份校验，如果通过校验，应该返回给用户一个认证的凭据--token;用户再访问别的应用的时候就会将这个token带上，作为自己认证的凭据，应用系统接受到请求之后会把token送到认证系统进行校验，检查token的合法性。如果通过校验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了 。
Token(令牌)
token的意思是“令牌”，是服务端生成的一串字符串，作为客户端进行请求的一个标识。
当用户第一次登录后，服务器生成一个token并将此token返回给客户端，客户端收到token后把它存储起来，可以放在cookie或者Local Storage(本地存储)里。 以后客户端只需带上这个token前来请求数据即可，无需再次带上用户名和密码。
简单token的组成;uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，token的前几位以哈希算法压缩成的一定长度的十六进制字符串。为防止token泄露)。
设计token的值可以有以下方式
1、用设备mac地址作为token2、用sessionid作为token同域SSO原理分析
实际上，HTTP协议是无状态的，单个系统的会话由服务端Session进行维持，Session保持会话的原理是通过Cookie把sessionId写入浏览器，每次访问都会自动携带全部Cookie，在服务端读取其中的sessionId进行验证实现会话保持。同域下单点登录其实就是手写token代替sessionId进行会话认证。
token的生成
服务端生成token后，将token与user对象存储在Map结构中，token为Key，user对象为value，response.addCookie()生成新的Cookie，名为token，值为token的值。
token过期移除
将服务端的token从Map中移除，再删除浏览器端的名为token的Cookie。
认证流程
跨域SSO原理分析
当有多个系统时，认证机制的流程如下：
提供用户登录界面，供用户进行身份认证用户验证通过后，生成新token将token<->user 对存入全局MAP中供校验将token写入所有域的Cookie中页面重定向回原始请求URL分析
当系统有多个并且在不同域(domain)时，Cookie只会作用在当前域下。将token写入所有域的Cookie中才是解决跨域SSO的核心。
单点登录，即用户只登录一次，在其随后访问所有的授权的资源时，都不需要再次登录。本方案使用CAS产品为基础来实现。
CAS(Central Authentication Service) 是 Yale 大学发起的一个开源项目，据统计，大概每 10 个采用开源构建 Web SSO 的 Java 项目，就有 8 个使用 CAS 。下方主要介绍CAS结构体系、协议与安全性。
CAS结构体系
从结构体系看， CAS 包含两部分：
1) CAS Server
CAS Server 负责完成对用户的认证工作， CAS Server 需要独立部署。
CAS Server 会处理用户名 / 密码等凭证 (Credentials) ，可通过连接到LADP检索用户名密码信息，也可能在 XML 文件中检索用户密码，对这种方式， CAS 均提供一种灵活但统一的接口 / 实现分离的方式， CAS 究竟是用何种认证方式，跟 CAS 协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。
2) CAS Client
CAS Client 负责部署在客户端(注意，我是指 Web 应用)，原则上， CAS Client 的部署意味着，当有对本地 Web 应用的受保护资源的访问请求，并且需要对请求方进行身份认证， Web 应用不再接受任何的用户名密码等类似的 Credentials ，而是重定向到 CAS Server 进行认证。
CAS协议
1) 基础协议
CAS 基础模式
上图是一个最基础的 CAS 协议， CAS Client 以 Filter 方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个 Web 请求，同时， CAS Client 会分析 HTTP 请求中是否包请求 Service Ticket( 上图中的 Ticket) ，如果没有，则说明该用户是没有经过认证的，于是， CAS Client 会重定向用户请求到 CAS Server ( Step 2 )。 Step 3 是用户认证过程，如果用户提供了正确的 Credentials ， CAS Server 会产生一个随机的 Service Ticket ，然后，缓存该 Ticket ，并且重定向用户到 CAS Client (附带刚才产生的 Service Ticket )， Service Ticket 是不可以伪造的，最后， Step 5 和 Step6 是 CAS Client 和 CAS Server 之间完成了一个对用户的身份核实，用 Ticket 查到 Username ，因为 Ticket 是 CAS Server 产生的，因此，所以 CAS Server 的判断是毋庸置疑的。
该协议完成了一个很简单的任务，就是 User(ah.zhangsan) 打开 IE ，直接访问 某一应用A，它被立即重定向到 CAS Server 进行认证， User 可能感觉到浏览器在 应用A 和 casserver 之间重定向，但 User 是看不到， CAS Client 和 CAS Server 相互间的 Service Ticket 核实 (Validation) 过程。当 CAS Server 告知 CAS Client 用户 Service Ticket 对应确凿身份， CAS Client 才会对当前 Request 的用户进行服务。
2) CAS 如何实现 SSO
CAS 可以很简单的实现跨域的 SSO ，因为，单点被控制在CAS Server ，用户最有价值的 TGC-Cookie 只是跟 CAS Server 相关， CAS Server 就只有一个，因此，解决了 cookies 不能跨域的问题。
1.如果 User 的持有 TGC 且其还没失效，那么就进行基础协议图的 Step4 ，达到了 SSO 的效果。
2.如果 TGC 失效，那么用户还是要重新认证进行基础协议图的 Step3。
CAS安全性
CAS 的安全性是一个非常重要的 Topic 。 CAS 从 v1 到 v3 ，都很依赖于 SSL ，它假定了这样一个事实，用户在一个非常不安全的网络环境中使用 SSO ， Hacker 的 Sniffer 会很容易抓住所有的 Http Traffic ，包括通过 Http 传送的密码甚至 Ticket 票据。
2.3.1 TGC/PGT 安全性
对于一个 CAS 用户来说，最重要是要保护它的 TGC ，如果 TGC 不慎被 CAS Server 以外的实体获得， Hacker 能够找到该 TGC ，然后冒充 CAS 用户访问所有授权资源。
SSO 的安全性问题比普通应用的安全性还要严重，因为 SSO 存在一种门槛效应。以前即使 Hacker 能够截获用户在 Web 应用 A 的密码，它也未必能知道用户在 Web 应用 B 的密码，但 SSO 让 Hacker 只需要截获 TGC( 突破了门槛 ) ，即能访问所有与该用户相关的所有应用系统。
PGT 跟 TGC 的角色是一样的，如果被 Hacker 获得，后果可想而知。
从基础模式可以看出， TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保 CAS 的安全性。 所以CAS 的传输安全性依赖于SSL 。
2.3.2 Service Ticket/Proxy Ticket 安全性
Service Ticket 是通过 Http 传送的，意味着所网络中的其他人可以 Sniffer 到其他人的Ticket 。
CAS 协议从几个方面让 Service Ticket 变得更加安全。
· Service Ticket 只能使用一次
CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会将服务端的缓存中清除该 Ticket，从而可以确保一个 Service Ticket 不被使用两次。
· Service Ticket 在一段时间内失效。
假设用户拿到 Service Ticket 之后，他请求 helloservice 的过程又被中断了， Service Ticket 就被空置了，事实上，此时， Service Ticket 仍然有效。 CAS 规定 Service Ticket 只能存活一定的时间，然后 CAS Server 会让它失效。通过在 web.xml 中配置下面的参数，可以让 Service Ticket 在多少秒内失效。该参数在业务应用的条件范围内，越小越安全。
· Service Ticket 是基于随机数生成的
Service Ticket 必须足够随机，如果 Service Ticket 生成规则被猜出(如果你使用了 ST+Helloservice+ 自增序列的方式， Hacker 就可以构造下一个 Ticket )，Hacker 就等于绕过 CAS 认证，直接访问所有服务。
CAS客户端配置
单点登录客户端集成，主要也就是配置了四个过滤器，和一个监听器。并且我们需要将用户信息和各个子系统进行同步。同时单点登录服务端配置了SSL，需要各个子系统导入证书到JDK中。
