|
现在的大型分布式项目，基本都会考虑实现单点登录，而且现在网上也有很多单点登录的实现方案、开源项目，但是针对单点登录的实现原理，讲解的并不是很细。大家可以参考其他开源案例项目，再结合本系列文章，可以对单点登录有较为深入的认识。
如果你对单点登录是什么也不知道，那就先看本文，了解单点登录的含义吧。
一. 单点登录
1. 产生背景
很早的时候，一家公司里可能只有一个Server，后来慢慢的Server开始变多了，而每个Server都要进行注册登录，退出的时候又要一个个退出，用户体验很不好！
比如，我们想访问百度系列，要登录百度知道、百度新闻、百度贴吧、百度图册......百度旗下的每一个产品，我们都分别注册一次账号，都分别登陆一次，都分别退出登录，这样一个一个Server去操作，可能会让人抓狂。
那么有没有办法，优化这样的登录体验呢？比如：一个公司名下的任意服务只需一次注册，登录的时候只要一次登录，退出的时候只要一次退出。如果可以实现这样的需求，用户体验是不是会有很大的提升？那么该用什么实现呢？
2. 多系统中的登录实现方案
想在多系统项目中实现登录，目前有2种可行的实现方案：
同域名下共享Cookie
单点登录
3. 共享Cookie方案的缺陷
虽然同域名下共享Cookie的方式，可以在一定程度上解决多系统中的登录问题，但是该方案存在众多局限性，如下：
应用的群域名必须统一；
应用群中各系统使用的Web技术(至少是Web服务器)要相同，否则cookie中key的名称(Tomcat为JSESSIONID)不同，无法维持会话；
共享Cookie的方式无法实现跨语言技术平台登录，比如无法在Java、PHP、.Net等之间共享Cookie；
Cookie本身也不安全。
4. SSO的概念
单点登录(Single Sign On)，简称为SSO，是目前比较流行的企业业务整合的解决方案之一。SSO是指在多应用系统中，用户只需要在某一个应用上登录一次，就可以同时在所有相关又彼此独立的系统中共享登录态。
即只登录一次，就能访问所有相互信任的应用系统，在其他所有系统中也都得到了授权而无需再次登录。另外用户也只需要退出一次，即可退出所有其他可信的服务。所以SSO包括单点登录与单点注销两部分。
5. SSO的优点
单点登录降低了用户的登录成本；
统一了不同系统之间的账号体系；
减少了各个系统在用户设计上付出的精力。
6. 使用场景
一般每个单独的系统都会有自己的安全体系和身份认证系统。在整合以前，进入每个系统都需要进行登录，这样的局面不仅给管理上带来了很大的困难，在安全方面也埋下了重大的隐患。下面是一些著名的调查公司显示的统计数据：
用户每天平均要花 16 分钟在身份验证任务上 - 资料来源：IDS
频繁的 IT 用户平均有 21 个密码 - 资料来源：NTA Monitor Password Survey
49% 的人写下了其密码，而 67% 的人很少改变它们
每 79 秒出现一起身份被窃事件 - 资料来源：National Small Business Travel Assoc
全球欺骗损失每年约 12B - 资料来源：Comm Fraud Control Assoc
在使用“单点登录”整合后，只需要登录一次就可以进入多个系统，而不需要重新登录。这不仅仅带来了更好的用户体验，更重要的是降低了安全的风险和管理的消耗。请看下面的统计数据：
提高 IT 效率：对于每 1000 个受管用户，每用户可节省$70K；
帮助台呼叫减少至少1/3，对于 10K 员工的公司，每年可以节省每用户 $75，或者合计 $648K；
生产力提高：每个新员工可节省 $1K，每个老员工可节省 $350 资料来源：Giga；
ROI 回报：7.5 到 13 个月 资料来源：Gartner
另外，使用 “单点登录” 还是SOA微服务时代的需求之一。在面向服务的架构中，服务和服务之间，程序和程序之间的通讯大量存在，服务之间的安全认证是SOA应用的难点之一。
应此建立“单点登录”的系统体系能够大大简化SOA的安全问题，提高服务之间的合作效率。
7. 单点登录执行流程(重点)
在单点登录系统中，需要定义一个独立的认证中心，只有认证中心才能接受用户的用户名密码等安全信息，而其他系统并不提供登录入口，只接受认证中心的间接授权，间接授权通过令牌实现。
SSO认证中心验证用户的用户名密码时如果没有问题，则创建授权令牌。在接下来的跳转过程中，授权令牌会作为参数发送给各个子系统，子系统拿到授权令牌，即得到了授权，可以借此创建局部会话，局部会话的登录方式与单系统的登录方式相同。
通过以上的SSO单点登录执行流程，我们可以得知，用户登录成功之后，会与SSO认证中心及各个子系统之间建立会话。
用户与SSO认证中心建立的会话称为全局会话，用户与各个子系统建立的会话称为局部会话，局部会话建立之后，用户访问子系统受保护资源将不再通过SSO认证中心。全局会话与局部会话有如下约束关系：
局部会话存在，全局会话一定存在；
全局会话存在，局部会话不一定存在；
全局会话销毁，局部会话必须销毁。
单点登录涉及到SSO认证中心与众多子系统，各子系统与SSO认证中心之间需要通信以交换令牌、校验令牌及发起注销请求，因而各子系统必须集成SSO客户端，SSO认证中心则是SSO服务端，整个单点登录过程实质是SSO客户端与服务端通信的过程。
8. 单独注销执行流程(重点)
在多应用系统中，我们既然实现了单点登录，自然也要单点注销，即在一个子系统中注销后，所有子系统的会话都将被销毁。
SSO认证中心会一直监听全局会话的状态，一旦发现全局会话被销毁，监听器将通知所有注册系统执行注销操作。
二. CAS单点登录系统
1. CAS概念
前文我们给大家介绍过，如果在一个企业旗下的所有系统都使用同一的顶级域名，其实实现单点登录也挺简单，我们只需要将Cookie的domain域设置为顶级域名，在服务器端进行会话共享即可。但是现实中并没有这么理想的状态，一般实现单点登录的成本是比较高的，接下来我给大家介绍一个实现单点登录的开源项目CAS，可以大大降低实现单点登录的难度和开发成本。
CAS(Central Authentication Service)，即中心认证服务系统。在CAS系统中，分为CAS Server与CAS Client两部分，CAS Server是单点登录系统中负责验证的服务端，CAS Client是CAS Server登录态的客户端。
2. CAS的核心概念(重点)
在CAS系统中有三个重要的术语：
Ticket Grantfng Ticke(TGT)：这是用户登录后生成的票根，包含用户的认证身份、有效期等信息，存储于CAS Server中，类似于我们常见的服务器会话；
Ticket Granted Cookie(TGC)：这是存储在Cookie中的一段数据，类似于会话ID，用户与CAS Server进行交互时，帮助用户找到对应的TGT；
Service Ticket(ST)：这是CAS Server使用TGT签发的一张一次性票据，CAS Client 使用ST与CAS Server进行交互，以获取用户的验证状态。
3. CAS单点登录执行步骤(重点)
CAS单点登录的完整步骤如下：
（1）用户先通过浏览器访问CAS Client程序的某个页面，例如http://cas.client.com/me；
（2）当CAS Client判断用户需要进行身份认证时，会携带service作为请求参数，并返回302状态码，指示浏览器重定向到CAS Server端，例如 http://cas.server.com/?service=http://cas. client.com/me.service，service是用户的原访问页面；
（3）然后浏览器利用 service 重定向到CAS Server；
（4）CAS Server 获取并校验用户cookie中携带的TGC，如果成功，则身份认证完成；否则将用户重定向到CAS Server 提供的登录页，例如 http://cas.server.com/login?service=http://cas. client.com/me，由用户输入用户名和密码，完成身份认证；
（5）如果用户已经登录过系统，那么CAS Server可以直接获取用户的TGC，并根据TGC找到TGT。如果是首次登录，则CAS Server 会首先生成TGT。每次验证时，CAS Server 会根据 TGT签发一个ST，并把ST拼接在service参数中，同时将相应的TGC设置到用户的cookie中(域为CAS Server)，并返回302 状态码，指示浏览器重定向到 service，例如 http://cas.client.com/me?ticket=XXX；
（6）浏览器存储TGC，并携带ST重定向到service；
（7）CAS Client取得ST(即请求参数中的ticket)后，会向CAS Server请求验证该ST的有效性；
（8）若CAS Server验证该ST是有效的，就告知CAS Client该用户有效，并返回该用户的信息。
CAS Client在获取用户信息时，可以使用session的形式管理用户会话。后续的交互请求不再需要重定向到CAS Server，CAS Client直接返回用户请求的资源即可。
 |
