锁定老帖子 主题:一种SSO的实现方案
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2007-09-04
跨域的融合应用,企业内网的自动化办公应用与放置在公网上的应用集成 流程: 1、用户通过浏览器登陆集成的门户<o:p></o:p> 2、集成的门户返回页面,用户选择外域提供的功能链接<o:p></o:p> 3、链接发送到跨域接口模块<o:p></o:p> 4、跨域接口模块解密藏在cookie中的集成门户颁发的登陆票,获取userid,跨域接口模块生成一个重定向到外域应用门户网页,并将用户ID及本域服务器身份认证信息放置到自动提交的隐藏表单中。隐藏表单的提交地址是外域的页面地址<o:p></o:p> 5、跨域接口模块把网页返回给浏览器,浏览器自动提交隐藏表单,请求发送外域WEB服务器。外域服务器登陆用户。<o:p></o:p> <o:p> </o:p> 特点:<o:p></o:p> 1、后续请求不过跨域接口模块,直接与外域WEB服务器连接<o:p></o:p> 2、对同一个用户,本域WEB服务器与外域WEB服务器维护的是独立的两个COOKIE,有独立的超时时间。本域应用用户logout后,外域应用会话有可能还存活。<o:p></o:p> 3、基于安全考虑,本域的传递到外域服务器的信息可以进行加密。<o:p></o:p> <o:p></o:p> 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2007-09-08
怎么没下文了啊
|
|
返回顶楼 | |
发表时间:2007-09-08
"本域应用用户logout后,外域应用会话有可能还存活。"
这个是很严重的问题.应该当成缺陷,而不应该当作 特点. 解决办法还是需要一台中央认证服务器(可以用任何一个所有服务器都能访问到的机器). 另外这期间可以利用rpc(或者是rest)来减少客户端与服务器的交互(同时可以提高安全性). 补充一下,我觉得利用ajax+ hession(一个轻量级RPC组件)+ REST(简单的就可以 可以参考江南白衣的那篇用httpClient组件实现简单REST的文章)+EHCACHE 肯定可以做出一个很不错的 轻量级的 SSO方案来 楼主如果对这个感兴趣欢迎和我一起探讨. 我以前做过一个简单的 但是很不成熟,一直想做个稍微好点的 ,但是没时间没精力啊 呵呵 |
|
返回顶楼 | |
发表时间:2007-09-08
引用 2、对同一个用户,本域WEB服务器与外域WEB服务器维护的是独立的两个COOKIE,有独立的超时时间。本域应用用户logout后,外域应用会话有可能还存活。 你这样的意思是登录后,外域服务器和本地域服务器之间就不再有任何联系和通信?或者说是两个不同的身份认证中心了? |
|
返回顶楼 | |
发表时间:2007-09-09
我描述的不是SSO普适的案例,描述的是一种COOKIE信息传递的外域的方法。其背景是企业内网门户集成公网上的应用界面。对大型的企业,内部的IT系统管理安全要求会比较高,并且希望系统间接口尽量少,出问题的时候避免厂家的互相推卸责任。
1、企业的内网服务器不能为公网访问,企业中的浏览器通过另外的企业管理的httpProxy,连接到公网,所以处在外域的被企业门户集成的应用不能在LOGOUT的时候告诉企业门户,以便将Session登出。在设计上单点登出也没有作为要求。 2、外域应用在登陆后就与企业的内部应用没有关系,既是安全上的要求,也对原有系统修改最少。 |
|
返回顶楼 | |
发表时间:2007-09-10
shallon 写道: 业务场景:
跨域的融合应用,企业内网的自动化办公应用与放置在公网上的应用集成 流程: 1、用户通过浏览器登陆集成的门户<o:p></o:p> 2、集成的门户返回页面,用户选择外域提供的功能链接<o:p></o:p> 3、链接发送到跨域接口模块<o:p></o:p> 4、跨域接口模块解密藏在cookie中的集成门户颁发的登陆票,获取userid,跨域接口模块生成一个重定向到外域应用门户网页,并将用户ID及本域服务器身份认证信息放置到自动提交的隐藏表单中。隐藏表单的提交地址是外域的页面地址<o:p></o:p> 5、跨域接口模块把网页返回给浏览器,浏览器自动提交隐藏表单,请求发送外域WEB服务器。外域服务器登陆用户。<o:p></o:p> <o:p> </o:p> 特点:<o:p></o:p> 1、后续请求不过跨域接口模块,直接与外域WEB服务器连接<o:p></o:p> 2、对同一个用户,本域WEB服务器与外域WEB服务器维护的是独立的两个COOKIE,有独立的超时时间。本域应用用户logout后,外域应用会话有可能还存活。<o:p></o:p> 3、基于安全考虑,本域的传递到外域服务器的信息可以进行加密。<o:p></o:p> <o:p></o:p> 这玩样的设计思路同cas如出一辙.而且还可以给你加强一下,用户登入任一系统时如果没有当前用户信息则redirect到统一登陆门户. 问题是你要修改其他应用的登陆模块,厂商们肯么? 而且sso的难度不在login验证,而在于用户信息在多系统之间的同步以及各系统之间的独立授权(统一授权基本不可行.我从来就没有看到有两家厂商产品天然的就能统一授权). |
|
返回顶楼 | |
发表时间:2007-10-05
我们单位的SSO场景:其他厂商的系统一点都不能更改。我们打算采用shallon的方案。
有一点疑问: 1。"...藏在cookie中的集成门户颁发的登陆票..." 登陆票的结构和生成规则是什么样子的? 2。"...并将用户ID及本域服务器身份认证信息放置到自动提交的隐藏表单中" 隐藏表单的作用很明显,只是里面的密码隐藏域存放的是密码明文吗? |
|
返回顶楼 | |
发表时间:2007-10-08
不是有个开源的sso实现的么
|
|
返回顶楼 | |
发表时间:2008-05-28
有很多所谓的登陆的话,就是从统一登录系统中想办法把用户信息传递到另外的系统。这似乎是多家企业开发的系统要作统一登录的惯用方案,实现也比较简单,反正就是一个转发,session都是自己系统的。不过如果是新系统的话,还是fins说的建立一个登录信息的管理中心比较好,将来要做什么改变或者扩展也好弄。
|
|
返回顶楼 | |
发表时间:2008-05-28
登录信息的管理中心一旦建立,就会造成所有的系统都对这个管理中心产生依赖。如果这个管理中心无法正常工作呢?是不是所有的系统都倒了?
我还是倾向Session信息使用各自系统自己的,在Session上做一些处理,针对用户登录信息,到统一的地方去读比较好。不要让这个统一的地方有处理功能,因为那个依赖性太强。仅让其作为一个存储空间并具备超时机制就可以了。 |
|
返回顶楼 | |
浏览 10632 次