Spring Security系列教程25--Spring Security实现CAS单点登录上篇--概述
Spring Security系列教程25--Spring Security实现CAS单点登录上篇--概述
前言
从本章节开始,会给各位讲解一个很常见也很重要的知识点,就是单点登录!现在的大型分布式项目,基本都会考虑实现单点登录,而且现在网上也有很多单点登录的实现方案、开源项目,但是针对单点登录的实现原理,讲解的并不是很细。你可以参考其他开源案例项目,再结合本系列文章,就可以对单点登录有较为深入的认识。
如果你对单点登录是什么也不知道,那就先看本文,了解单点登录的含义吧。
一. 单点登录
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,或者合计75,或者合计 75,或者合计648K;
- 生产力提高:每个新员工可节省 1K,每个老员工可节省1K,每个老员工可节省 1K,每个老员工可节省350 资料来源:Giga;
- ROI 回报:7.5 到 13 个月 资料来源:Gartner
另外,使用 “单点登录” 还是SOA微服务时代的需求之一。在面向服务的架构中,服务和服务之间,程序和程序之间的通讯大量存在,服务之间的安全认证是SOA应用的难点之一。应此建立“单点登录”的系统体系能够大大简化SOA的安全问题,提高服务之间的合作效率。
7. 单点登录执行流程(重点)
在单点登录系统中,需要定义一个独立的认证中心,只有认证中心才能接受用户的用户名密码等安全信息,而其他系统并不提供登录入口,只接受认证中心的间接授权,间接授权通过令牌实现。SSO认证中心验证用户的用户名密码时如果没有问题,则创建授权令牌。在接下来的跳转过程中,授权令牌会作为参数发送给各个子系统,子系统拿到授权令牌,即得到了授权,可以借此创建局部会话,局部会话的登录方式与单系统的登录方式相同。 这个过程,就是单点登录的原理,我们用下图来详细说明。
根据上图,我们可以梳理出单点登录的请求执行流程(重点):
- 比如用户访问系统1的受保护资源,结果系统1发现用户未登录,会先跳转到SSO认证中心,并将自己的地址作为参数,比如login.xxx.com/jump?target… ;
- 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程序的某个页面,例如cas.client.com/me;
- 当CAS Client判断用户需要进行身份认证时,会携带service作为请求参数,并返回302状态码,指示浏览器重定向到CAS Server端,例如 cas.server.com/?service=ht…,service是用户的原访问页面;
- 然后浏览器利用 service 重定向到CAS Server;
- CAS Server 获取并校验用户cookie中携带的TGC,如果成功,则身份认证完成;否则将用户重定向到CAS Server 提供的登录页,例如 cas.server.com/login?servi…cas.client.com/me,由用户输入用户名和密码,完成身份认证;
- 如果用户已经登录过系统,那么CAS Server可以直接获取用户的TGC,并根据TGC找到TGT。如果是首次登录,则CAS Server 会首先生成TGT。每次验证时,CAS Server 会根据 TGT签发一个ST,并把ST拼接在service参数中,同时将相应的TGC设置到用户的cookie中(域为CAS Server),并返回302 状态码,指示浏览器重定向到 service,例如 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服务端!