前言

从本章节开始，一一哥 会给各位讲解一个很常见也很重要的知识点，就是单点登录！现在的大型分布式项目，基本都会考虑实现单点登录，而且现在网上也有很多单点登录的实现方案、开源项目，但是针对单点登录的实现原理，讲解的并不是很细。你可以参考其他开源案例项目，再结合本系列文章，就可以对单点登录有较为深入的认识。

如果你对单点登录是什么也不知道，那就先看本文，了解单点登录的含义吧。

一. 单点登录

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分钟的时间在身份验证任务上
• 频繁的 IT 用户平均有 21 个密码
• 49% 的人设置了密码后，而 67% 的人则很少会再改变它们
• 每 79 秒出现一起身份被窃事件
• 全球欺骗损失每年约 12B

在使用“单点登录”之后，只需要登录一次就可以进入多个系统，而不需要重新登录。这不仅仅带来了更好的用户体验，更重要的是降低了安全的风险和管理的消耗。请看下面的统计数据：

• 提高 IT 效率：对于每 1000 个受管用户，每用户可节省$70K；
• 帮助台呼叫减少至少1/3，对于 10K 员工的公司，每年可以节省每个用户 $75，或者合计 $648K；
• 生产力提高：每个新员工可节省 $1K，每个老员工可节省 $350
• ROI 回报：7.5 到 13 个月

另外，使用 “单点登录” 还是SOA微服务时代的需求之一。在面向服务的架构中，服务和服务之间，程序和程序之间的通讯大量存在，服务之间的安全认证是SOA应用的难点之一。应此建立“单点登录”的系统体系能够大大简化SOA的安全问题，提高服务之间的合作效率。

7. 单点登录执行流程(重点)

在单点登录系统中，需要定义一个独立的认证中心，只有认证中心才能接受用户的用户名密码等安全信息，而其他系统并不提供登录入口，只接受认证中心的间接授权，间接授权通过令牌实现。SSO认证中心验证用户的用户名密码时如果没有问题，则创建授权令牌。在接下来的跳转过程中，授权令牌会作为参数发送给各个子系统，子系统拿到授权令牌，即得到了授权，可以借此创建局部会话，局部会话的登录方式与单系统的登录方式相同。这个过程，就是单点登录的原理，我们用下图来详细说明。

根据上图，我们可以梳理出单点登录的请求执行流程(重点)：

1. 比如用户访问系统1的受保护资源，结果系统1发现用户未登录，会先跳转到SSO认证中心，并将自己的地址作为参数，比如http://login.xxx.com/jump?target=http://系统1.com/xxx ；
2. SSO认证中心发现用户未登录，则将用户引导到登录页面，并将系统1的地址作为参数带过去；
3. 用户输入用户名和密码，向SSO认证中心提交登录申请，并将系统1的地址作为参数带过去；
4. SSO认证中心校验用户信息，校验成功后，会创建一个用户与SSO认证中心之间的会话，称之为全局会话，同时创建一个授权令牌；
5. SSO认证中心带着令牌跳转回最初的请求地址(系统1)；
6. 系统1拿到授权令牌后，接着去SSO认证中心校验令牌是否有效，并将系统1的地址作为参数带过去；
7. SSO认证中心先校验令牌是否有效，正常则返回有效信息，并把系统1的信息注册进SSO授权中心；
8. 系统1使用该授权令牌创建出与用户的会话，称为局部会话，然后给用户返回受保护的资源；
9. 如果用户继续访问系统2的受保护资源，也会与SSO授权中心进行交互授权；
10. 比如系统2发现用户未登录，则跳转到SSO认证中心，并将自己的地址作为参数携带过去；
11. 如果SSO认证中心发现用户已登录，则跳转回系统2的地址，并带过去授权令牌；
12. 系统2拿到授权令牌，接着会去SSO认证中心校验授权令牌是否有效；
13. SSO认证中心也会校验授权令牌，并返回有效信息，把系统2的信息也注册进行SSO授权中心；
14. 系统2使用该授权令牌创建一个与用户的局部会话，并返回受保护的资源。

通过以上的SSO单点登录执行流程，我们可以得知，用户登录成功之后，会与SSO认证中心及各个子系统之间建立会话。用户与SSO认证中心建立的会话称为全局会话，用户与各个子系统建立的会话称为局部会话，局部会话建立之后，用户访问子系统受保护资源将不再通过SSO认证中心。全局会话与局部会话有如下约束关系：

1. 局部会话存在，全局会话一定存在；
2. 全局会话存在，局部会话不一定存在；
3. 全局会话销毁，局部会话必须销毁。

单点登录涉及到SSO认证中心与众多子系统，各子系统与SSO认证中心之间需要通信以交换令牌、校验令牌及发起注销请求，因而各子系统必须集成SSO客户端，SSO认证中心则是SSO服务端，整个单点登录过程实质是SSO客户端与服务端通信的过程。

8. 单独注销执行流程(重点)

在多应用系统中，我们既然实现了单点登录，自然也要单点注销，即在一个子系统中注销后，所有子系统的会话都将被销毁。我们用下图来说明。

SSO认证中心会一直监听全局会话的状态，一旦发现全局会话被销毁，监听器将通知所有注册系统执行注销操作。下面对上图进行简要说明：

1. 比如用户向系统1发起注销请求；
2. 系统1根据用户与系统1建立的局部会话id拿到授权令牌，接着系统1向SSO认证中心发起注销请求；
3. SSO认证中心会先校验授权令牌是否有效，然后销毁全局会话，同时取出所有用此授权令牌注册的系统地址；
4. SSO认证中心向所有注册系统发起注销会话的请求；
5. 各注册系统接收到SSO认证中心的注销请求，销毁局部会话；
6. 最后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直接返回用户请求的资源即可，整个流程如下图所示：

请各位把上面的单点登录执行流程和CAS的核心概念牢固掌握，这些知识点有助于我们后文知识点的理解和掌握。敬请期待下文，如何搭建CAS服务端！