单点登录,Single Sign On,也就是我们平时所说的SSO。一般大型的系统平台,都会用到这个东西。它解决了频繁登录、验证的过程,也就是用户的一次登录得到其他系统的信任。可以说:一次登录,全站漫游。实现单点登录,说简单一些,就是解决如何产生和存储那个信任,再就是其他系统如何验证这个信任的有效性。因此,也就需要解决以下两点:
- 存储信任
- 验证信任
只要解决了上述两个问题,其实也就解决了SSO。
看到这里,我们不禁会思考,这样很简单啊,将那个信任放置到客户端的Cookie中,就能搞定啊。嗯,确实可以。
但是,这样搞的话,随之而来的问题是:Cookie的安全性和跨域问题。
对于Cookie的安全性问题,我们一般通过加密Cookie来处理。关于跨域的问题,这种解决方案,确实是硬伤。通过查找资料,也有解决的方法:这种方案的思路就是把这个信任关系存储在客户端,完了都去客户端验证。要实现这个也不一定只能用Cookie,用flash也能解决,flash的Shared Object API就提供了这种存储能力。
在大型系统中,一般采用在服务端存储信任关系的解决方案:
这种解决方案,就是把信任关系存储在单独的SSO系统中,比如CAS。
一般说来,大型应用会把授权的逻辑与用户信息的相关逻辑独立成一个应用,称为用户中心。用户中心不处理业务逻辑,只是处理用户信息的管理以及授权给第三方应用。第三方应用需要登录的时候,则把用户的登录请求转发给用户中心进行处理,用户处理完毕返回凭证,第三方应用验证凭证,通过后就登录用户。
但是,其中还是有一些问题需要注意:
- 如何高效存储大量临时性的信任数据
- 如何防止信息传递过程中被篡改
- 如何让SSO系统信任登录系统和免登录系统
对于第一个问题,一般采用Redis这样的分布式缓存方案,既能提供可扩展数据量的机制,也能提供高效的访问。对于第二个问题,一般采用数字签名的方法,要么通过数字证书签名,要么通过类似于MD5的方式。这就需要SSO系统返回免登录URL的时候,对需要验证的参数进行MD5加密,并带上token一起返回,最后需要免登录的系统进行验证信任关系的时候,需要把这个token传给SSO系统,SSO系统通过对token的验证就可以辨别信息是否被修改。最后一个问题,可以通过白名单来处理,说简单点就是:只有在白名单上的系统才能请求产生信任关系。
以上只是提供了些简单的实现技术,但需要强调的是只是技术实现而已,仅仅是为了解决上面谈到的一些问题。