前两天看到一个帖子《多站点整合—单点登录简单方案》,一直没顾得上回复。我想,Sohu并不仅仅为了“需要设计一个统一的登录界面”而考虑,它在安全性、授权机制上下了很大功夫。在这里对作者Zesson的分析做一些补充。<o:p></o:p>
需要统一登录界面是SSO(Single Sign On)的一个典型场景,此外相关的还有认证,同步,授权与统一登出等等,最为复杂的往往是同步,授权这两个环节。SSO直译过来叫单点登录,是对Portal这个继续流行的企业业务整合方案的另一种称谓。由于整合范围和技术不同,主要有Web层单点登录、跨越Web层单点登录(Web与传统系统),传统系统单点登录(Portal)等等。<o:p></o:p>
记得2004年在做某单位的Protal系统时,因为要整合很多来自不同编程语言(PB,VB,Dephi),不同编程时期的程序,遇到很多极为棘手的问题,调整方案往往对现有系统造成伤筋动骨的伤害,或者根本就是重做,最后系统也不了了之。而现在在Web层实现单点登录相较就简单了很多,比如在我们建立的Portal页面上有每个网站的链接,用户点击这些链接就可以了。<o:p></o:p>
<o:p> </o:p>
J,当然还有更好的形式,我们先回顾一下基础知识。<o:p></o:p>
因为HTTP 协议是无状态的,我们想在Web开发中维持服务器段的应用状态可以利用Session。而基于Web的身份验证实质是用户在表单中输入用户名和密码后提交,服务器从Request中提取用户名和密码,通过第一次验证后用Session来存储客户的登录信息。以后每次Request过来时,便从Session中读取这些信息,如果有则进入相应界面,没有则认为未登录。<o:p></o:p>
而Cookie特性则帮助我们在客户端维持状态。服务器在HTTP的Response头上加上一行以提示浏览器按照指示生成相应的Cookie。Cookie主要有名字,值,过期时间,路经和域这些字段。浏览器会按照一定的时间原则在后台自动发送给服务器,如果Cookie声明的作用范围大于等于将要请求的资源所在位置,则把该Cookie附在Request头上。<o:p></o:p>
如果设置了Cookie的有效期,浏览器就会把Cookie保存到硬盘上,这个Cookie可以在不同的浏览器中实现共享。如果不设置有效期或者设置为负数,这个Cookie将保存在内存中。对于内存中的Cookie,IE与同一IE新建窗口的进程可以共享,而与其它方式打开的(如“我的电脑”)IE进程则不能共享;JavaScript的window.open打开的窗口可以与原窗口共享;FireFox的进程或标签页可以共享。关闭浏览器,内存中的Cookie就终止了。<o:p></o:p>
服务器端为每一个Session编号,以便提取与某个具体的交互过程相关的Session,同时也需要在客户端保存编号以区分具体的交互过程,这样便可以利用Cookie。 如果浏览器设置为禁用Cookie,服务器可以利用Request的提交来维持Session在客户端的标志。在地址栏中看到类似于JSessionID=xxxxxxxx的就是Get方式,服务器在返回请求时总是将与该交互过程相关的SessionId追加到URL上,以保持状态。也可以在返回的HTML的Form表单中追加hidden,将Session标志放进去,Form提交往往是Post方式。浏览器关闭时并不会通知服务器,如果Cookie保存在硬盘上,那么关掉浏览器再打开还会继续前面的Session。因此服务器端需要对Session设置一个期限,多长时间未收到客户端的请求将让Seesion实效。<o:p></o:p>
综上,如果浏览器登录过某Web系统,服务器端生成了Session,客户端的Cookie中记录了SessionId,浏览器没有关闭,即使使用内存中的Cookie,访问其它Web系统再回来只要Session没有失效,服务器还是会认为登录是有效的。因此利用Cookie便可以达到SSO。浏览器登录Web A的页面后生成一个Cookie,再访问Web B的页面时通过访问服务器端通过Cookie就可以判断该客户段是否已成功登录。基于这样思路的就是SSO的Agent方式。<o:p></o:p>
<o:p> </o:p>
目前SSO有两种主流实现方案,Agent和Proxy。如果是非跨域的情况,还有共享Session的方式,如WebLogic和金蝶。<o:p></o:p>
Agent方式是,增加一台SSO认证服务器,然后在每一个Web应用系统上安装一个Agent,由它访问SSO认证服务器来实现统一的身份验证和访问控制。SSO认证服务器存储了各Web应用系统的用户之间的映射方式。这样的缺点是必须改造现有系统。<o:p></o:p>
一次SSO过程大致为:<o:p></o:p>
1. 用户第一次访问Web A的页面<o:p></o:p>
2. Web A发现用户未登录<o:p></o:p>
3. Web A 调用AgentA<o:p></o:p>
4. AgentA将页面转向SSO Auth<o:p></o:p>
5. SSO Auth 返回登录页面<o:p></o:p>
6. 用户输入用户名密码提交<o:p></o:p>
7. SSO Auth验证密码成功<o:p></o:p>
8. SSO Auth调用AgentA的URL传递帐号信息<o:p></o:p>
9. AgentA解密帐号信息,传送给Web A<o:p></o:p>
10. Web A进行授权,返回原来请求的页面<o:p></o:p>
11. 用户访问Web B<o:p></o:p>
12. Web B发现用户未登录,调用AgentB<o:p></o:p>
13. AgentB将页面转向SSO Auth<o:p></o:p>
14. SSO Auth发现用户已经登录<o:p></o:p>
15. SSO Auth调用AgentB的URL传递帐号信息<o:p></o:p>
16. AgentB解密帐号信息,传送给Web B<o:p></o:p>
17. Web B进行授权,返回原来请求的页面<o:p></o:p>
由于第5步与第14步都是在同一域下进行的,因此可以直接访问浏览器中的Cookie,以验明正身,不存在跨域取Cookie的问题。<o:p></o:p>
Proxy方式有时也称之为Gateway,即通过DNS将多个系统的域名配置在一个承担SSO的Proxy Server上,同时还需要一个LDAP服务器。用户对各Web系统的访问首先被定向在Proxy Server,Proxy Server发现用户未登录,返回自己的登录页面。用户提交用户名密码,Proxy Server根据LDAP服务器查询原有系统的用户名和密码,再Post给用户访问的原系统。<o:p></o:p>
<o:p> </o:p>
看了Zesson的分析数据,我认为:<o:p></o:p>
1. Sohu使用的是Agent方式,但是对它有一些改动,不需要独立安装,在现有系统扩充一些代码就可以。<o:p></o:p>
2. 它的认证服务器映射了用户信息但不做验证,登录的验证由每个网站自己维护,在登录成功后通知其他网站(登录成功后在页面上生成每个Web系统的Token URL作为ticket)。<o:p></o:p>
3. 出于安全考虑,URL中只存放Token,不会存放用户相关的信息。<o:p></o:p>
Sohu SSO可能的过程如下:<o:p></o:p>
1. 用户登录Sohu的Passport的login,提交用户名密码<o:p></o:p>
2. Sohu login验证登录成功后返回,生成脚本http://passport.sohu.com/sso/crossdomain_all.jsp?action=login,刷iframe以来准备调用Agent<o:p></o:p>
3. Crossdomain_all回写/sso/crossdomain.jsp?action=login&domain=17173.com, 页面刷iframe调用Agent<o:p></o:p>
4. Sohu Agent将登录信息传递给 SSO<o:p></o:p>
5. SSO 生成Token或者包含Token的URL,返回Sohu Agent<o:p></o:p>
6. Sohu Agent 将调用其它网站Agent的URL传给页面,如pass.17173.com/sso/setcookie.jsp?passport= xxxxxxxxxxxx<o:p></o:p>
7. 页面刷iframe,调用17173的Agent<o:p></o:p>
8. 17173 Agent将Token(就是那个passport)传递给SSO获取验证<o:p></o:p>
9. SSO返回验证成功及17173用户信息<o:p></o:p>
10. 17173 Agent调用17173登录模块进行授权<o:p></o:p>
11. 17173登录模块在响应中设置Cookie<o:p></o:p>
在这里认为Sohu有统一认证的证据是,调用其它网站时所用的passport是一致的。<o:p></o:p>
由于前期开发时是各自为政(如Sohu和Chinaren),系统都有各自的认证和授权,后来合并后提取统一的方式比较困难,便使用了现在这种既灵活,侵入性也不大的方案。
分享到:
相关推荐
单点登录源码下了就知道!单点登录源码下了就知道!单点登录源码下了就知道!在IIS中配置站点 配置4个站点指向相应的目录,并分别指定4个站点的主机头: http://www.passport.com/ http://www.a.com/ ...
应用系统应该能对Token进行识别和提取,通过与认证系统的通讯,能自动判断当前用户是否登录过,从而完成单点登录的功能。 比如说,我现在有3个分站点和1个认证中心(总站)。当用户访问分站点的时候,分站点会发...
跨站点共享Session解决方案、单点登录解决方案(ASP.NET 2.0版本)通过序列化和反序列化机制实现的一种解决方案
asp.net 跨域单点登录实现。源码分为3个站点:一个总站,即认证中心,用来登录。
自己辛苦做的一个单点登录的Demo,虽然粗糙,但是不乏可借鉴指出,希望对大家有用!
Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种...该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。本实例还原了整个的使用流程。建议使用vs2019,framework4.8版本。
通过共同的sessionid在服务器端获得相同session信息,即可达到单点登录(即多站点共享用户信息,一处登录,处处可用)的目的。 单点登录分为两种情况: 一、站点部署在同一个服务器,且使用同一个二级域名 这种情况...
应用系统应该能对Token进行识别和提取,通过与认证系统的通讯,能自动判断当前用户是否登录过,从而完成单点登录的功能。 比如说,我现在有3个分站点和1个认证中心(总站)。当用户访问分站点的时候,分站点会发...
基于C# 开发的单点登录示例程序SSO ,讲解了三个子站点如何通过令牌实现互相认证登录功能。
VS2010编写的单点登陆源码,建议修改HOST文件部署成多个站点域名测试,文件中包括一个服务器和3个子站点, 单点登陆参考是的是京东的做法,在各自客户端通过脚本然后写入其他站点的cookie,而没有使用POST多站点的...
基于 RBAC 的 Net6 后台管理框架,权限管理,前后台分离,支持多站点单点登录,兼容所有主流浏览器,内置微信、支付宝、QQ等多种登录方式,内置多种样式,可切换至 Blazor 多 Tabs 模式,权限控制细化到网页内任意...
该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务...
SSO单点登录,代码都有注释,需要发布至少三个站点,开发环境:vs2017,win10,.NET Core2.0+MVC
基于 RBAC 的 Net7 后台管理框架,权限管理,前后台分离,支持多站点单点登录,兼容所有主流浏览器,内置微信、支付宝、QQ等多种登录方式,内置多种样式,可切换至 Blazor 多 Tabs 模式,权限控制细化到网页内任意...
一个简单的单点登录功能,实现了跨域的单点登录 多个站点之间只需登录一次
站点接入方案 www.huawei.com HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential 核心网软交换CE 的现状和分类 承载网B网 内部AR/PE 内部AR/PE 外部AR/PE 169 外部AR/PE Gi WAP流量 Gi流量 按照机房来部署CE,CE成...
ASP.NET跨域单点登录源码 asp.net 跨域单点登录实现原理: 当用户第一次访问web应用系统1的时候,因为还没有登录,会被引导到认证中心进行登录; 根据用户提供的登录信息,认证系统进行身份效验,如果 通过效验...
基于 RBAC 的 Net7 后台管理框架,权限管理,前后台分离,支持多站点单点登录,兼容所有主流浏览器,内置微信、支付宝、QQ等多种登录方式,内置多种样式,可切换至 Blazor 多 Tabs 模式,权限控制细化到网页内任意...
asp.net 跨域单点登录实现原理: 当用户第一次访问web应用系统1的时候,因为还没有登录,会被引导到认证中心进行登录;根据用户提供的登录信息,认证系统进行身份效验,如果 通过效验,返回给用户一个认证的凭据;...
mvc 下的单点登录,实现,适合多个站点的运维审计等。