前言：从本章开始，一一哥 向大家介绍常见的重要知识点。 单点登录。 目前的大型分布式项目基本上都在考虑实现单点登录。 另外，目前互联网上也有很多单点登录的实现方案、开源项目，但对于单点登录的实现原理，却鲜有详细说明。 通过参考其他开源案例项目并结合本系列文章，可以对单点登录有更深的了解。
如果你对单点登录一无所知，请先看这篇文章，了解单点登录的含义吧。
1 .单点登录1 .背景产生很早的时候，一家公司可能只有一台服务器。 此后，服务器开始逐渐增多，但每台服务器都必须注册登录，注销时又要一个一个地注销。 用户体验不好。 例如，我们想访问百度系列。 百度知道、百度新闻、百度贴吧、百度专辑……为百度旗下的每个产品注册一个账号，分别注册，然后分别结束注册。 像这样委托一个个的服务器进行操作的话，可能会很烦躁。
那么，有没有优化这种登录体验的方法？ 例如，某公司名下的任何服务只注册一次，注册时只注册一次，退出时只退出一次。 如果能实现这样的需求，用户体验不是会大幅提高吗？ 那么，用什么来实现呢？
2 .多系统下登录实现方案希望通过多系统项目实现登录，目前有两种可行的实现方案。
域名共享Cookie单点登录3 .共享Cookie方案通过缺陷域名共享Cookie可以在一定程度上解决多系统登录问题，但该方案存在以下诸多局限性：
适用的集团域名应当统一； 确保APP应用程序组中的每个系统使用的Web技术(至少是Web服务器)相同。 否则，cookie的key的名称(Tomcat为JSESSIONID )将不同，无法保持会话。 共享cookie的方法无法在不同语言技术平台之间登录，例如无法在Java、PHP、 Net等之间共享cookie，cookie本身也不安全。 4. SSO概念单点登录(Single Sign On)，简称为SSO是目前流行的企业业务集成解决方案之一。SSO是指在多应用系统中，用户只需要在某一个应用上登录一次，就可以同时在所有相关又彼此独立的系统中共享登录态。这意味着您只需登录一次，就可以访问所有相互信任的APP应用程序系统，其他所有系统也无需再次登录即可获得授权。 此外，用户只要退出一次，就可以退出所有其他受信任的服务。 所以SSO包括单点登录与单点注销两部分。
5. SSO优势单点登录降低了用户登录成本； 减少各个系统在设计用户时花费的精力，这些系统统一了不同系统之间的帐户结构。 6 .使用场景一般每个系统都有自己的安全系统和认证系统。 在整合之前，每个系统都需要登录才能访问，这不仅给管理带来了巨大的困难，而且在安全方面也埋下了巨大的风险。 以下是知名调查公司提供的统计数据：
用户每天平均花16分钟在认证任务上-资料来源： IDS频繁的IT用户平均有21个密码-资料来源： NTAmonitorpasswordsurvey有49%的人写了密码。 67%的人几乎没有改变每79秒一起身份被盗的事件-数据源： nationalsmallbusinesstravelassoc全球诈骗损失约12B -数据源： comm fraud control 一次只需登录多个系统就可以访问多个系统，这不仅能带来更好的用户体验，而且降低安全风险和管理消耗也很重要。 请看以下统计数据：
提高IT效率：每1,000名管理用户节约$70K； 帮助台呼叫减少至少1/3，10 k员工的公司每年可节约每用户$75或总计$648K，从而提高工作效率：节约每名新员工$1K、每名资深员工$350的数据源： ROI收益率： 7.5~13个月数据源： Gartner还表示，使用“单点登录”是SOA微服务时代的需求之一。 在面向服务的体系结构中，存在大量服务与服务之间、程序与程序之间的通信，服务之间的安全认证是SOA APP应用的难点之一。 该应建立“单点登录”的系统体系可以大大简化SOA的安全问题，提高服务之间的合作效率。
7 .单点登录执行流程(重点) http://www.Sina.com/http://www.Sina.com /
的跳转过程中，授权令牌会作为参数发送给各个子系统，子系统拿到授权令牌，即得到了授权，可以借此创建局部会话，局部会话的登录方式与单系统的登录方式相同。这个过程，就是单点登录的原理，我们用下图来详细说明。根据上图，我们可以梳理出单点登录的请求执行流程(重点)：
比如用户访问系统1的受保护资源，结果系统1发现用户未登录，会先跳转到SSO认证中心，并将自己的地址作为参数，比如http://login.xxx.com/jump?target=http://系统1.com/xxx ；SSO认证中心发现用户未登录，则将用户引导到登录页面，并将系统1的地址作为参数带过去；用户输入用户名和密码，向SSO认证中心提交登录申请，并将系统1的地址作为参数带过去；SSO认证中心校验用户信息，校验成功后，会创建一个用户与SSO认证中心之间的会话，称之为全局会话，同时创建一个授权令牌；SSO认证中心带着令牌跳转回最初的请求地址(系统1)；系统1拿到授权令牌后，接着去SSO认证中心校验令牌是否有效，并将系统1的地址作为参数带过去；SSO认证中心先校验令牌是否有效，正常则返回有效信息，并把系统1的信息注册进SSO授权中心；系统1使用该授权令牌创建出与用户的会话，称为局部会话，然后给用户返回受保护的资源；如果用户继续访问系统2的受保护资源，也会与SSO授权中心进行交互授权；比如系统2发现用户未登录，则跳转到SSO认证中心，并将自己的地址作为参数携带过去；如果SSO认证中心发现用户已登录，则跳转回系统2的地址，并带过去授权令牌；系统2拿到授权令牌，接着会去SSO认证中心校验授权令牌是否有效；SSO认证中心也会校验授权令牌，并返回有效信息，把系统2的信息也注册进行SSO授权中心；系统2使用该授权令牌创建一个与用户的局部会话，返并回受保护的资源。通过以上的SSO单点登录执行流程，我们可以得知，用户登录成功之后，会与SSO认证中心及各个子系统之间建立会话。用户与SSO认证中心建立的会话称为全局会话，用户与各个子系统建立的会话称为局部会话，局部会话建立之后，用户访问子系统受保护资源将不再通过SSO认证中心。全局会话与局部会话有如下约束关系：
局部会话存在，全局会话一定存在；全局会话存在，局部会话不一定存在；全局会话销毁，局部会话必须销毁。单点登录涉及到SSO认证中心与众多子系统，各子系统与SSO认证中心之间需要通信以交换令牌、校验令牌及发起注销请求，因而各子系统必须集成SSO客户端，SSO认证中心则是SSO服务端，整个单点登录过程实质是SSO客户端与服务端通信的过程。
8. 单独注销执行流程(重点)在多应用系统中，我们既然实现了单点登录，自然也要单点注销，即在一个子系统中注销后，所有子系统的会话都将被销毁。我们用下图来说明。
SSO认证中心会一直监听全局会话的状态，一旦发现全局会话被销毁，监听器将通知所有注册系统执行注销操作。下面对上图进行简要说明：
比如用户向系统1发起注销请求；系统1根据用户与系统1建立的局部会话id拿到授权令牌，接着系统1向SSO认证中心发起注销请求；SSO认证中心会先校验授权令牌是否有效，然后销毁全局会话，同时取出所有用此授权令牌注册的系统地址；SSO认证中心向所有注册系统发起注销会话的请求；各注册系统接收到SSO认证中心的注销请求，销毁局部会话；最后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单点登录的完整步骤如下：
用户先通过浏览器访问CAS Client程序的某个页面，例如http://cas.client.com/me；当CAS Client判断用户需要进行身份认证时，会携带service作为请求参数，并返回302状态码，指示浏览器重定向到CAS Server端，例如 http://cas.server.com/?service=http://cas.client.com/me.service，service是用户的原访问页面；然后浏览器利用 service 重定向到CAS Server；CAS Server 获取并校验用户cookie中携带的TGC，如果成功，则身份认证完成；否则将用户重定向到CAS Server 提供的登录页，例如 http://cas.server.com/login?service=http://cas.client.com/me，由用户输入用户名和密码，完成身份认证；如果用户已经登录过系统，那么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；浏览器存储TGC，并携带ST重定向到service；CAS Client取得ST(即请求参数中的ticket)后，会向CAS Server请求验证该ST的有效性；若CAS Server验证该ST是有效的，就告知CAS Client该用户有效，并返回该用户的信息。CAS Client在获取用户信息时，可以使用session的形式管理用户会话。后续的交互请求不再需要重定向到CAS Server，CAS Client直接返回用户请求的资源即可，整个流程如下图所示：
请各位把上面的单点登录执行流程和CAS的核心概念牢固掌握，这些知识点有助于我们后文知识点的理解和掌握。敬请期待下文，如何搭建CAS服务端！