假设我们需要在如下子系统 **.a1.a2 **.b1.b2 **.c1.c2间实现单点登录，首先我们需要一个专门用于单点登陆的认证系统(sso.s1.s2)。假设目前系统处于未登录状态，访问为例：
分别看一下每个步骤作用：
收到请求，检查是否携带登录的cookie，目前没有登陆过，那么重定向到sso认证中心
SSO提供登陆窗口，用户输入用户名 口令。SSO系统验证用户名和口令
这一步是关键，如果登录成功，首先把SSO系统的Cookie放到客户端；同时，将用户的认证信息传递通过重定向传递给业务方，注意，这个传递明显不能通过cookie来传递（不同域嘛），一般是通过加密的querystring。
业务方的验证系统收到sso认证信息，再进行认证
业务方认证通过之后，把认证结果的cookie写入到.a1.a2，至此，SSO认证完成
重定向到业务系统,由前面的结论可知，此时所有以.a1.a2结尾的业务系统都可以使用这个认证之后的cookie
response
说明:
业务认证系统不一定存在，有些不是太敏感的系统可以直接从SSO Authorization重定向到业务系统，并把SSO的认证信息带过去。
与访问不同的是我们在重定向到SSO Authorization时已经不需要再去输入用户名，因为sso.s1.s2此时已经存有cookie，直接用cookie验证。
以上，就是一个简单的基于Cookie的登陆系统。
其中几个问题需要重点解决
如何高效存储大量临时性的信任数据
如何防止信息传递过程被篡改
如何让SSO系统信任登录系统和免登系统
对于第一个问题，一般可以采用类似与memcached的分布式缓存的方案，既能提供可扩展数据量的机制，也能提供高效访问
对于第二个问题，一般采取数字签名的方法，要么通过数字证书签名，要么通过像md5的方式，这就需要SSO系统返回免登URL的时候对需验证的参数进行 md5加密，并带上token一起返回，最后需免登的系统进行验证信任关系的时候，需把这个token传给SSO系统，SSO系统通过对token的验证 就可以辨别信息是否被改过
对于最后一个问题，可以通过白名单来处理，说简单点只有在白名单上的系统才能请求生产信任关系，同理只有在白名单上的系统才能被免登录。
您可能感兴趣的文章: