为什么需要单点登录
单点登录SSO(Single Sign On)说得简单点就是在一个多系统共存的环境下,用户在一处登录后,就不用在其他系统中登录,也就是用户的一次登录能得到其他所有系统的信任。
单点登录在大型网站里使用得非常频繁,例如,阿里旗下有淘宝、天猫等网站,还有背后的成百上千的子系统,用户一次操作或交易可能涉及到几十个子系统的协作,如果每个子系统都需要用户认证,不仅用户会疯掉,各子系统也会为这种重复认证授权的逻辑搞疯掉。
所以,单点登录要解决的就是,用户只需要登录一次就可以访问所有相互信任的应用系统。
单点登录的来源
1.早期web单系统应用
早期我们开发web应用都是所有的包放在一起打成一个war包放入tomcat容器来运行的,所有的功能,所有的业务,后台管理,门户界面,都是由这一个war来支持的,这样的单应用,也称之为巨石应用,因为十分不好扩展和拆分。
在巨石应用下,用户的登录以及权限就显得十分简单,当浏览器向服务器发送登录请求时,验证通过之后,会将用户信息存入seesion
中,然后服务器会生成一个sessionId
放入cookie
中,随后返回给浏览器。
大致可以用下图来表示:
验证登录的这个会话就是session,维护了用户状态,也就是所谓的HTTP有状态协议,我们经常可以在浏览器中看到JSESSIONID,这个就是用来维持这个关系的key。
2.分布式集群部署
由于网站的访问量越来也大,单机部署已经是巨大瓶颈,所以才有了后来的分布式集群部署。
例如:如果引入集群的概念,单应用可能重新部署在3台tomcat以上服务器,使用nginx来实现反向代理。
但是增加新的服务器之后,不同的服务器之间的sessionId是不一样的,可能在A服务器上已经登录成功了,能从服务器的session中获取用户信息,但是在B服务器上却查不到session信息,只好退出来继续登录,结果A服务器中的session因为超时失效,登录之后又被强制退出来要求重新登录。
所以不得不考虑多服务器之间的session数据一致的问题,这就是单点登录的最早来源。
单点登录的实现方式
单点登录的本质就是在多个应用系统中共享登录状态,如果用户的登录状态是记录在 Session 中的,要实现共享登录状态,就要先共享 Session。
所以实现单点登录的关键在于,如何让 Session ID(或 Token)在多个域中共享。
1.同域下的单点登录
一个企业一般情况下只有一个域名,通过二级域名区分不同的系统。
比如我有个域名:mikechen.cc,同时有两个业务系统分别为:
blog.mikechen.cc video.mikechen.cc
我们要做单点登录(SSO),需要一个登录系统,叫做:sso.mikechen.cc。
我们只要在sso.mikechen.cc登录,blog.mikechen.cc和video.mikechen.cc也登录了。
实现方式:其实这里就是利用了 二级域名 写 一级域名的 Cookie 。sso.mikechen.cc登录以后,可以将Cookie的域设置为顶域,即.mikechen.cc,这样所有子域blog.mikechen.cc和video.mikechen.cc的系统都可以访问到顶域的Cookie。
此种实现方式比较简单,但不支持跨主域名,局限性限于一级域名是一样的。
2.不同域下的单点登录
同域下的单点登录是巧用了Cookie顶域的特性,如果是不同域呢,比如:下面三个是不同域的
mikechen1.cc mikechen2.cc mikechen3.cc
实现方式:我们可以部署一个SSO认证中心,认证中心就是一个专门负责处理登录请求。
所有的请求(登录、退出、获取用户信息、当前用户状态)都请求sso
系统,sso
系统维护用户信息。
此种实现方式相对复杂,支持跨域,扩展性好,是单点登录的标准做法。
基于SSO认证中心的开源项目代表:CAS,其中 CAS是Central Authentication Service,即中央认证服务,下图是CAS的基本过程:
以上就是基于单点登录的介绍!
作者简介
陈睿|mikechen,10年+大厂架构经验,就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注作者「mikechen」公众号,获取更多技术干货!
后台回复【架构】,即可获取《阿里架构师进阶专题全部合集》,后台回复【面试】即可获取《史上最全阿里Java面试题总结》