Alfred Sun +

单点登录 SSO 的实现原理

Posted by Alfred Sun technique

单点登录 SSO(Single Sign On)说得简单点就是在一个多系统共存的环境下,用户在一处登录后,就不用在其他系统中登录,也就是用户的一次登录能得到其他所有系统的信任。

单点登录在大型网站里使用得非常频繁,例如像阿里巴巴这样的网站,在网站的背后是成百上千的子系统,用户一次操作或交易可能涉及到几十个子系统的协作,如果每个子系统都需要用户认证,不仅用户会疯掉,各子系统也会为这种重复认证授权的逻辑搞疯掉。

实现单点登录说到底就是要解决如何产生和存储那个信任,再就是其他系统如何验证这个信任的有效性,因此要点也就以下几个:

只要解决了以上的问题,达到了开头讲得效果就可以说是 SSO。

客户端实现

最简单实现 SSO 的方法就是用 Cookie,实现流程如下所示:

Storage of trust on Client

不难发现以上的方案是把信任存储在客户端的 Cookie 里,这种方法虽然实现方便但立马会让人质疑两个问题:

对于第一个问题一般都是通过加密 Cookie 来处理;
第二个问题是硬伤,其实这种方案的思路的就是要把这个信任关系存储在客户端,要实现这个也不一定只能用 Cookie,用 flash 也能解决,flash 的 Shared Object API 就提供了存储能力。

服务端实现

一般说来,大型系统会采取在服务端存储信任关系的做法,实现流程如下所示:

Storage of trust on Server

以上方案就是要把信任关系存储在单独的 SSO 系统(暂且这么称呼它)里,说起来只是简单地从客户端移到了服务端,但其中几个问题需要重点解决:

  1. 如何高效存储大量临时性的信任数据?
  2. 如何防止信息传递过程被篡改?
  3. 如何让 SSO 系统信任登录系统和免登系统?

对于第一个问题,一般可以采用类似与 memcached 的分布式缓存的方案,既能提供可扩展数据量的机制,也能提供高效访问。
对于第二个问题,一般采取数字签名的方法,要么通过数字证书签名,要么通过像 md5 的方式,这就需要 SSO 系统返回免登 URL 的时候对需验证的参数进行 md5 加密,并带上 token 一起返回,最后需免登的系统进行验证信任关系的时候,需把这个 token 传给 SSO 系统,SSO 系统通过对 token 的验证就可以辨别信息是否被改过。
对于最后一个问题,可以通过白名单来处理,说简单点只有在白名单上的系统才能请求生产信任关系,同理只有在白名单上的系统才能被免登录。

结束语

以上只是提供了些简单的实现技术,但需要强调的是这只是技术实现而已,仅仅是为了解决上面谈到的一些问题,SSO 本身来说并不是什么高科技,有了这个认识比较有利于我们深入探索 SSO。

[Comments]:

Related Blog