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