Single Sign-On(SSO)单点登陆的具体实现方案
2010-10-12 15:04
453 查看
我们都知道网易、搜狐等大型门户都有“通行证”的概念,这个通行证系统就是今天讨论的“单点登录系统”。其主要特征是多个站点一个用户中心,一点登陆后其他也自动登录,注销也是。比如我们在126登录了邮箱,再去163.com就是登陆状态。我这里的实现方案是传统的cookie方案。希望此文对需要的朋友有用,也希望不足之处大家能够提出。
例如 http://sso.a.com/login?url=http://www.b.com ,登录之后,我们Response一个cookie,并且将其domain设为 a.com顶级域,这样只要是同域的站点都可以直接访问到这个cookie。
由于cookie不能跨域,所以这里要解决不同域下的cookie问题。解决办法就是通过JS API来获取a.com的cookie信息,并通过url传递个b.com。
我们知道ajax是不能跨域访问的,但是我们可以<script>一个跨域的JS(这就是JSAPI),所以SSO系统需要提供一个callback参数,输出为一段js代码。
SSO输出cookie给调用者,接受callback参数
var user = Request.Cookies["Username"];
var callback = Request.QueryString["callback"];
if(user!=null)
Response.Write(callback+"("+user.ToJson()+")");//ToJson是一个扩展方法,将对象序列化为Json格式
b.com获取cookie的办法
$.getScript("http://sso.a.com/getcookie?callback=setuser");
function setuser(data)
{
if(data!=null)
{
var user = eval(data);
alert("hello"+user.Username);
}
setcookie(user);//将得到的cookie写在本地
}
通过这种办法,我们的b.com便可以通过得到的cookie知道该用户是否登录。
验证登录可以有2种办法:
一种是上面提到的通过JSAPI知道cookie是否存在来判断其他系统是否注销
另外一种是在本地已存cookie的情况下通过WebService由服务端去验证该用户是否还在登陆状态。
这两种办法各有优缺点,第一种是不需要知道本地是否有cookie的,第二种需要借助webService,但增加的检验的严谨性。
假如我们在b.com做重要的数据操作,最好通过服务端检验来判定登陆状态,如果从cookie来判断,则必须保证cookie无法伪造,也就是得对cookie进行加密,解密。
如果通过WebService客户端的cookie同样需要一个无法伪造的标识,比如GUID,但不需要加密,只需要与服务端的GUID和UserName进行匹配即可。但是明显通过WebService的压力要远大于解密cookie。如果站点居多且访问量很高,那这种验证请求会对SSO造成巨大压力。
希望有想法的朋友发表评论。
SSO的基本功能:
·统一登录
所有站点的登录都要跳转至SSO来登录,同时附带刚刚请求的url参数,以便登陆后返回。例如 http://sso.a.com/login?url=http://www.b.com ,登录之后,我们Response一个cookie,并且将其domain设为 a.com顶级域,这样只要是同域的站点都可以直接访问到这个cookie。
由于cookie不能跨域,所以这里要解决不同域下的cookie问题。解决办法就是通过JS API来获取a.com的cookie信息,并通过url传递个b.com。
我们知道ajax是不能跨域访问的,但是我们可以<script>一个跨域的JS(这就是JSAPI),所以SSO系统需要提供一个callback参数,输出为一段js代码。
SSO输出cookie给调用者,接受callback参数
var user = Request.Cookies["Username"];
var callback = Request.QueryString["callback"];
if(user!=null)
Response.Write(callback+"("+user.ToJson()+")");//ToJson是一个扩展方法,将对象序列化为Json格式
b.com获取cookie的办法
$.getScript("http://sso.a.com/getcookie?callback=setuser");
function setuser(data)
{
if(data!=null)
{
var user = eval(data);
alert("hello"+user.Username);
}
setcookie(user);//将得到的cookie写在本地
}
通过这种办法,我们的b.com便可以通过得到的cookie知道该用户是否登录。
·统一注销
每个站点注销都必须连接到sso.a.com/logout来实现注销,删除cookie。·验证登录
为了实现同时注销功能,比如bbs.a.com注销了,www.b.com必须知道,所以b.com的所有需要知道登陆状态的请求都必须访问一次sso.a.com来验证是否还在登录。验证登录可以有2种办法:
一种是上面提到的通过JSAPI知道cookie是否存在来判断其他系统是否注销
另外一种是在本地已存cookie的情况下通过WebService由服务端去验证该用户是否还在登陆状态。
这两种办法各有优缺点,第一种是不需要知道本地是否有cookie的,第二种需要借助webService,但增加的检验的严谨性。
假如我们在b.com做重要的数据操作,最好通过服务端检验来判定登陆状态,如果从cookie来判断,则必须保证cookie无法伪造,也就是得对cookie进行加密,解密。
如果通过WebService客户端的cookie同样需要一个无法伪造的标识,比如GUID,但不需要加密,只需要与服务端的GUID和UserName进行匹配即可。但是明显通过WebService的压力要远大于解密cookie。如果站点居多且访问量很高,那这种验证请求会对SSO造成巨大压力。
·服务端设计
如果SSO还有其他压力大的工作,则需要多台机器部署。多台部署就会有一个Session问题,所以服务端的用户登录状态不能把Session存于InProc中,也不能是StatusServer中,只能是SqlServer中。而我的解决办法是放在分布式缓存(Memcached)中,当然其实已经不是Session了,而是普通的缓存列表。把Username和Guid放在Memcached中,做成hash表,能够很快的找到某个用户的登陆情况(Guid和请求的一致)·授权白名单
SSO会暴露一些WebService接口给站点使用,所以不能随便被别人所利用,这时就需要验证请求的ip是否为授权的地址)希望有想法的朋友发表评论。
相关文章推荐
- Single Sign-On(SSO)单点登陆的具体实现方案
- Single Sign-On(SSO)单点登陆的具体实现方案【转载】
- 单点登录 SSO(Single Sign-On)的实现原理
- WebSphere环境下的SSO(Single sign-on:单点登录、全网漫游)实现之: -- SSO实现技术准备
- WebSphere环境下的SSO(Single sign-on:单点登录、全网漫游)实现之: 二 SSO(Single Sign-On)实现步骤
- 单点登陆 SSO(Single Sign-On) 简介
- sso 之 搜狐单点登陆实现方案
- WebSphere环境下的SSO(Single sign-on:单点登录、全网漫游)实现之---- SSO实现技术准备
- WebSphere环境下的SSO(Single sign-on:单点登录、全网漫游)实现之---- SSO(Single Sign-On)实现步骤
- 单点登陆(Single Sign-On,SSO)介绍(翻译)
- 浏览器三种刷新方式的缓存机制-----单点登录SSO的实现原理---PHP版单点登陆实现方案
- SSO(Single Sign-on) in Action
- [导入]Single-Sign-On(SSO) 在你的应用程序里实现统一身份认证
- 简单的asp.net模拟邮箱系统基础实现(二 (2)具体版块功能的实现及关键代码之登陆页面)
- SSO单点登陆方案整理
- GoogleReader用户登陆验证C#具体实现
- 单点登陆,SSO英文全称Single Sign On
- SSO单点登陆方案整理
- 数据库分库分表策略的具体实现方案
- 分享实现类似QQ的自动登陆的方法,代码比较简单,主要是给大家提供一个实现逻辑,具体的要结合自身的app来做