一、实现简单Web-SSO之总述

目录

一、总述
二、环境配置
[三、业务servers管理]
[四、用户信息同步]
[五、token的拦截、生成、验证(服务端)]
[六、概念辨析:session、cookie、token的区别与token存储]
[七、token的分享(浏览器端)]
[八、安全性措施]
[九、用户体验]
[十、性能]


关于没有后续更新的问题

各位,实在抱歉!SSO原本是我的毕业设计,但是出于某个原因,我决定留级,毕设暂时搁浅!这段时间忙着准备面试的事情,系统学习前端中ing! 这是这个系列被搁浅的原因之一!另一个原因在于,我发现没有经历过企业开发,真的在某些环节上很难理解SSO中一些让我非常困惑的问题!比如,我一直困惑的这个问题,这非常有可能是一个很简单的问题,但是我往往是被这种问题困惑住。比如,“性能”问题,大四实习年一直没在IT企业,讨论“性能”心里很虚,我更想接触一定的开发之后,心里更加有底的写下问题的答案。没出问题的话,这个系列会在6月中旬继续更新,希望8月能搞定。


经商之道

今天我要讲两个故事,一家高级商场的故事和一家普通商场的故事。

1.高级商场的故事

从前有个老板叫C/S,他开了这样一家高级商场叫“TCP/IP Server"。专门服务注册了VIP的顾客。他们对待注册了VIP的顾客的服务非常的高级。怎样高级?每一位VIP顾客进来购物,就会有一个服务员全程陪同。这些服务员提供所有的服务,非常的有才能。但就是都很没有记性,永远都记不住自己是在服务哪位顾客。这也怪不得服务员,谁叫每个VIP顾客都长得一模一样呢?于是老板就让服务员全程牵着顾客的手,并且手里拿着一张纸条,纸条上面写着顾客的姓名、性别、年龄、余额等等信息。这样他们就能叫出顾客的尊称,而且因为牵着手,所以不至于跟顾客走丢。真为这一群奇葩着急啊ヽ( ̄д ̄;)ノ!!!这些服务员这一群体被学术家们称为“progress”,而顾客这一群体被学术家们称为“client”

我很好奇高级商场卖的都是些什么东西。从商业角度来说,全程一对一的服务成本可真高啊。

2.普通商场的故事

后来,有一个老板叫B/S,他觉得C/S是个傻X,全程一对一的服务成本高,收益小。于是他开了一家普通的商场叫"HTTP Server"。跟"TCP/IP Server"商场一样,他的"HTTP Server"也是需要注册VIP的。但是他的服务员们并不会全程陪同顾客购物。总的来说,他们提供两样服务:1.询问 2.收银。每个服务员在处理完某个顾客的询问服务或者收银服务后,就可以为另一个顾客服务。"B/S"以为它的商场会比那个没头脑的“C/S”的商场收益更好!很显然嘛,一样多的服务员,他的店能服务更多的顾客。

天真的B/S,可怜的B/S。他差点就破产了~ 还不是那群让人着急的服务员!开张第一天,他们就惹来了满满的差评。他们总是记不住顾客买了什么东西,根本没有办法收银;而且顾客上前要询问他们“node.js的产品在哪个货架?”、“Python有多少种框架产品?”等问题的时候,这群服务员总是没有办法先叫出顾客的名字来给予顾客问候。顾客觉得他们都很没有礼貌~~~这也怪不得服务员,健忘是他们的天性,更何况每个顾客的相貌、穿着、声音又都完全一样,他们可是要一个人服务多个顾客的!

B/S决定关店整改!!!他给每个服务员配备了一个记录器。有一个服务员专门负责把进店的会员信息写进记录器,然后把一串唯一的ID写在一种叫做cookie的纸上,把纸贴在顾客额头上......没错,贴在额头上。其它服务员只要往记录器输入顾客头上的ID,就能查询到顾客的信息,这样服务员就不会因为叫不出顾客的名字被说没礼貌了;并且可以把顾客要买的东西,临时的记录在记录器里面。当然啦,记录器里的记录是整个商场共享的。所以,即便顾客A买《黑客与画家》的时候是服务员A给记录的,买《写给大家看的设计书》的时候是服务员B给记录的,结算的时候又是服务员C,他们搞错了。 B/S非常自豪的把这种记录器机制叫做session机制,真搞不懂他为什么要这么叫。就这样,B/S“HTTP Server”商场以更低的成本获得了更大的收益~ 他发迹了。

登录这件事

登录就是通过验证(密码验证、指纹验证、声音验证、人面验证、DNA验证...),向服务端表明你是谁?并且让服务端记住你是谁。对于C/S的架构来说,要记住你是谁太容易了~ 客户端跟服务端建立的TCP/IP连接就能很好的表明你谁,一个进程服务一个客户端,只要在进程空间里写个变量就OK了!但是对于B/S架构来说,因为是无状态的,服务一结束就断开(现在的长连接也还是会断),要记住你是谁真心太不容易了~ 所以只能由客户端来告诉服务端:“我是谁。”,也就是给客户端一个ID,然后服务端有个全局的空间(session)用于记录ID对于的信息,类似于Map<ID, infomations>。对于每一次的服务请求,服务端都要拿着客户端给的ID,去session查询这个ID是不是登录了,如果是则怎样怎样,如果不是就叫用户登录(假设每个页面的访问都要求用户登录)。拿着ID去session查询ID是不是登录了这个过程我们把它叫做检验,这点先提前说明下,有点重要!登录成功后,就把这个ID做一个标记,表示登录。什么样的标记?你可以在这个ID的session空间里设置一个变量叫mark用来表示登录了,但是不会有人这么做的,至少也得设置个username的变量。不然你怎么知道这个用户是哪一个用户呢?有username就可以再去数据库查询更多的信息,当然也可以把更多的信息写到session里面,这里不做讨论。

什么是单点登录(Single Sign-On)

很早期的公司,一家公司可能只有一个Server,慢慢的Server开始变多了。每个Server都要进行注册登录,退出的时候又要一个个退出。用户体验很不好!你可以想象一下,上豆瓣 要登录豆瓣FM、豆瓣读书、豆瓣电影、豆瓣日记......真的会让人崩溃的。我们想要另一种登录体验:一家企业下的服务只要一次注册,登录的时候只要一次登录,退出的时候只要一次退出。怎么做?

一次注册。 一次注册不难,想一下是不是只要Server之间同步用户信息就行了?可以,但这样描述不太完整,后续讲用户注册的时候详细说。实际上用户信息的管理才是SSO真正的难点,只是作为初学者,我们的难点在于实现SSO的技术!我们先讨论实现手段。

一次登录与一次退出。 回头看看普通商场的故事,什么东西才是保持登录状态关键的东西?记录器(session)?那种叫做cookie的纸张?写在纸张上的ID? 是session里面记录的信息跟那个ID,cookie只不是记录ID的工具而已。客户端持有ID,服务端持有session,两者一起用来保持登录状态。客户端需要用ID来作为凭证,而服务端需要用session来验证ID的有效性(ID可能过期、可能根本就是伪造的找不到对于的信息、ID下对应的客户端还没有进行登录验证等)。但是session这东西一开始是每个server自己独有的,豆瓣FM有自己的session、豆瓣读书有自己的session,而记录ID的cookie又是不能跨域的。所以,我们要实现一次登录一次退出,只需要想办法让各个server的共用一个session的信息,让客户端在各个域名下都能持有这个ID就好了。再进一步讲,只要各个server拿到同一个ID,都能有办法检验出ID的有效性、并且能得到ID对应的用户信息就行了,也就是能检验ID

单点登录的实现方法(server端)

以server群如何生成、验证ID的方式大致分为两种:

  • “共享Cookie”
    这个就是上面提到的共享session的方式,我倒觉得叫“共享session”来得好一点,本质上cookie只是存储session-id的介质,session-id也可以放在每一次请求的url里。据说这种方式不安全,我没去细究,哪位大神可以推荐下相关的资料,我后期补上。其实也是,毕竟session这项机制一开始就是一个server一个session的,把session拿出来让所有server共享确实有点奇怪。

  • SSO-Token方式
    因为共享session的方式不安全,所以我们不再以session-id作为身份的标识。我们另外生成一种标识,把它取名SSO-Token(或Ticket),这种标识是整个server群唯一的,并且所有server群都能验证这个token,同时能拿到token背后代表的用户的信息。我们要讨论的也是这种方式,一会上具体流程图。

单点登录的实现方法(浏览器端)

单点登录还有非常关键的一步,这一步跟server端验证token的方式无关,用最早的“共享session”的方式还是现在的“token”方式,身份标识到了浏览器端都要面临这样的一个问题:用户登录成功拿到token(或者是session-id)后怎么让浏览器存储和分享到其它域名下?同域名很简单,把token存在cookie里,把cookie的路径设置成顶级域名下,这样所有子域都能读取cookie中的token。这就是共享cookie的方式(这才叫共享Cookie嘛,上面那个应该叫共享session)。比如:谷歌公司,google.com是他的顶级域名,邮箱服务的mail.google.com和地图服务的map.google.com都是它的子域。但是,跨域的时候怎么办?谷歌公司还有一个域名,youtube.com,提供视频服务。如何把身份标识分享给youtube.com这个域?简单的先提下,后续会细说。

  • 利用带有src属性的HTML标签跨域设置cookie。例如:

    <iframe width = 0 height=0 src="youtube.com/set_sso_token?ssotoken=iurk2i3f">
    
  • url跳转。比如:在google.com登录后,会跳转到youtube.com下种植cookie,再跳转会google.com。

  • Ajax设置cookie(目前还不了解,据说京东是这么做的。)

SSO-Token方式的服务端流程

实际上,基本是用Token代替session的方式,也有非常多种实现方法。图片是我先去自己实验时的方案。

图片描述

SSO-Server负责用户的登录(当然也有注册、修改基本用户信息、退出功能),它的作用有两点:

  • 验证用户。就是验证账号密码。我们略过不关注

  • 生成唯一的token

  • 往其它业务Server同步token等信息,让各个业务server自己验证token有效性(如图); 或者,提供检验token有效性的API接口

我们要实现什么样的SSO

  • token生成与验证方案:如上图。

  • token在浏览器的跨域分享方法,都尝试一遍。

  • 安全性。暂时一律不考虑,我们先关注实现一个差劲的SSO,再来关注安全。因为安全是个大话题。太早引入,太拖节奏

  • 实现语言:node.js(express4.x)。其实感觉SSO的实现是语言无关的,一个node.js实现的登录server完全可以为一个python实现的业务server服务。server之间的关系最后都演化成web接口的调用。

阅读 8.7k

推荐阅读
单点登录
用户专栏

单点登录相关的技术、实现教程

2 人关注
2 篇文章
专栏主页