expr

使用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. 使用场景

在整合以前,进入每个系统都需要进行登录一般每个单独的系统都会有自己的安全体系和身份认证系统。,这样的局面不仅给管理上带来了很大的困难,在安全方面也埋下了重大的隐患。下面是一些著名的调查公司显示的统计数据:

a. 用户每天平均要花 16 分钟在身份验证任务上 - 资料来源:IDS

b. 频繁的 IT 用户平均有 21 个密码 - 资料来源:NTA Monitor Password Survey

c. 49% 的人写下了其密码,而 67% 的人很少改变它们

d. 每 79 秒出现一起身份被窃事件 - 资料来源:National Small Business Travel Assoc

e. 全球欺骗损失每年约 12B - 资料来源:Comm Fraud Control Assoc

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

a. 提高 IT 效率:对于每 1000 个受管用户,每用户可节省$70K;

b. 帮助台呼叫减少至少1/3,对于 10K 员工的公司,每年可以节省每用户 $75,或者合计 $648K;

c. 生产力提高:每个新员工可节省 $1K,每个老员工可节省 $350 资料来源:Giga;

d. ROI 回报:7.5 到 13 个月 资料来源:Gartner

另外,使用 “单点登录” 还是SOA微服务时代的需求之一。在面向服务的架构中,服务和服务之间,程序和程序之间的通讯大量存在,服务之间的安全认证是SOA应用的难点之一。

应此建立“单点登录”的系统体系能够大大简化SOA的安全问题,提高服务之间的合作效率。

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

在单点登录系统中,需要定义一个独立的认证中心,只有认证中心才能接受用户的用户名密码等安全信息,而其他系统并不提供登录入口,只接受认证中心的间接授权,间接授权通过令牌实现。

SSO认证中心验证用户的用户名密码时如果没有问题,则创建授权令牌。在接下来的跳转过程中,授权令牌会作为参数发送给各个子系统,子系统拿到授权令牌,即得到了授权,可以借此创建局部会话,局部会话的登录方式与单系统的登录方式相同。

这个过程,就是单点登录的原理,我们用下图来详细说明。

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

a. 比如用户访问系统1的受保护资源,结果系统1发现用户未登录,会先跳转到SSO认证中心,并将自己的地址作为参数,比如http://login.xxx.com/jump?target=http://系统1.com/xxx ;

b. SSO认证中心发现用户未登录,则将用户引导到登录页面,并将系统1的地址作为参数带过去;

c. 用户输入用户名和密码,向SSO认证中心提交登录申请,并将系统1的地址作为参数带过去;

d. SSO认证中心校验用户信息,校验成功后,会创建一个用户与SSO认证中心之间的会话,称之为全局会话,同时创建一个授权令牌;

e. SSO认证中心带着令牌跳转回最初的请求地址(系统1);

f. 系统1拿到授权令牌后,接着去SSO认证中心校验令牌是否有效,并将系统1的地址作为参数带过去;

g. SSO认证中心先校验令牌是否有效,正常则返回有效信息,并把系统1的信息注册进SSO授权中心;

h. 系统1使用该授权令牌创建出与用户的会话,称为局部会话,然后给用户返回受保护的资源;

i. 如果用户继续访问系统2的受保护资源,也会与SSO授权中心进行交互授权;

j. 比如系统2发现用户未登录,则跳转到SSO认证中心,并将自己的地址作为参数携带过去;

k. 如果SSO认证中心发现用户已登录,则跳转回系统2的地址,并带过去授权令牌;

l. 系统2拿到授权令牌,接着会去SSO认证中心校验授权令牌是否有效;

m. SSO认证中心也会校验授权令牌,并返回有效信息,把系统2的信息也注册进行SSO授权中心;

n. 系统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(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://casclient.com/me.service,service是用户的原访问页面;

(3)然后浏览器利用 service 重定向到CAS Server;

(4)CAS Server 获取并校验用户cookie中携带的TGC,如果成功,则身份认证完成;否则将用户重定向到CAS Server 提供的登录页,例如 http://cas.server.com/login?service=http://casclient.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直接返回用户请求的资源即可,整个流程如下图所示:

想要企业快速接入单点登录身份管理零信任,可以试试 OneAuth 身份云支持多种单点登录SSO标准协议,快速进行企业应用对接与管理。

OneAuth - 身份引擎云开创者 :基于引擎驱动的云原生的 SSO 单点登录平台覆盖全场景对于企业身份管理的需求。支持标准协议 SAML、OIDC、CAS 单点登录 SSO 以及非标准协议的支持。对于有特殊要求的用户 OneAuth 还支持私有化定制 PaaS 版本的部署。

通过 OneAuth 的应用生态适配上千个企业 SaaS 应用。支持各种主流身份源,通过 Active Directory、钉钉、企业微信、OIDC 协议 IDP、身份源的接入打通身份目录同步与认证能力,实现对人员、组织架构等多维度身份数据的集中储存及权限策略管理。轻松实现本地与云端应用间的身份信息同步,快速映射身份数据,打通各应用间身份数据阻隔的壁垒。




转载请注明,谢谢