|
锁定老帖子 主题：单点登录设计
精华帖 (1) :: 良好帖 (0) :: 新手帖 (3) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-09-26
最后修改：2011-09-26
fantasy 写道 可以使用独立的单点登录应用ssoApp来做，这样可扩展性和安全性会更好。
1：用户访问App1的某个URL，App1通过cookie（必须加密）去单点登录服务器验证当前用户是否已经登录，如果没有登录，则跳转到单点登录应用的登录页面，并传递用户访问的URL。 2：用户提交用户名和密码，单点登录应用验证登录成功后跳转回App1,并传递token和sign(用于防止token被篡改)。 3：App1将返回的token和sign通过接口去单点登录应用进行验证，如果验证成功跳转用户访问的URL,并写入登录成功的cookie。 4：用户退出App1，清空登录验证的cookie。 那么即使新增一个app2或app3，照样可以支持单点登录。 这就是 CAS 开源框架。 目前新浪微薄也是如此实现的。 |
| 返回顶楼 | |
|
发表时间：2011-09-26
sagahl 写道 CAS：基于Token SSO。侵入性太强，跳转太多，依赖于C的安全（一般是https），关键是登录页面都在C。
什么叫侵入性太强？跳转太多？关键是登录页都在C? 没有深入了解过，就不要这么肯定。它只是一套框架，一个解决方案，不是一个产品，不是拿来就用了上线的。只需要简单根据自身需求对其扩展，你说的这些都不是问题。 |
| 返回顶楼 | |
|
发表时间：2011-09-26
最后修改：2011-09-26
引用 如果是这样，就不需要cookie了，直接设置共享session来实现这个功能。
不需要cookie了？ 请问你知道 cookie 和 session 的关系吗？服务器如何将 session 与 用户的浏览器绑定的呢？没有浏览器中的 cookie，服务端的 session 再怎么共享也是无用。 当然如果你是通过使用一个 sid 或 tk 之类的在 URL 后作为参数传来传去就另谈别论了。 |
| 返回顶楼 | |
|
发表时间：2011-09-27
关注画图工具
|
| 返回顶楼 | |
|
发表时间：2011-09-27
denger 写道 sagahl 写道 CAS：基于Token SSO。侵入性太强，跳转太多，依赖于C的安全（一般是https），关键是登录页面都在C。
什么叫侵入性太强？跳转太多？关键是登录页都在C? 没有深入了解过，就不要这么肯定。它只是一套框架，一个解决方案，不是一个产品，不是拿来就用了上线的。只需要简单根据自身需求对其扩展，你说的这些都不是问题。 侵入性强是指对于web工程，cas其需要使用者参与的行为过多，客户端编码的侵入性太大。在原有的cas方案中，每次验证都是要跳转到C的，C hold住TGT（这里是CAS的关键）。通过TGT产生ST，再跳转回请求验证端，后台走API验证ST。在Token SSO基础上做了2次跳转，如果需要验证端不hold住自己的凭证，每次都是要去取ST的（交通银行的老系统就是这么做的），hold住登录凭证那是应用自己的事情（阿里巴巴中文站的做法）。CAS的设计意图是统一登陆协议，减少符合CAS协议SSO各个点的连接成本，但是协议本身有很多限制，也不符合大家的使用情况。我对sso了解不多，大概只研究了3年左右，有幸参与过某些银行系统的面等及国际较大电子商务网站的sso或OPEN API设计，如果你有兴趣，我们可以交流一下。 |
| 返回顶楼 | |
|
发表时间：2011-09-27
denger 写道 fantasy 写道 可以使用独立的单点登录应用ssoApp来做，这样可扩展性和安全性会更好。
1：用户访问App1的某个URL，App1通过cookie（必须加密）去单点登录服务器验证当前用户是否已经登录，如果没有登录，则跳转到单点登录应用的登录页面，并传递用户访问的URL。 2：用户提交用户名和密码，单点登录应用验证登录成功后跳转回App1,并传递token和sign(用于防止token被篡改)。 3：App1将返回的token和sign通过接口去单点登录应用进行验证，如果验证成功跳转用户访问的URL,并写入登录成功的cookie。 4：用户退出App1，清空登录验证的cookie。 那么即使新增一个app2或app3，照样可以支持单点登录。 这就是 CAS 开源框架。 目前新浪微薄也是如此实现的。 1.CAS不是开源框架，是一个协议。 2.不是有单点登录服务器就一定是CAS。Oauth，P3P SSO也是可以有单点登录服务器的。 综合来看，你对各种免登的方案知道的太少，张冠李戴，并且没有抓住各种免登方案的核心设计思想。 |
| 返回顶楼 | |
|
发表时间：2011-09-27
ironpearl 写道 minghuibo 写道 seesion的有效时间是可以设定的，一旦过期，就失效了，服务器端就找不到这个session了！也就是说你session.getAttribute()取到的是为NULL的，你可以通过这个区判断，lz的系统是公用一个session，那么一旦失效，就等重新登录了！
建议使用COOKIE 这样可移植性高 同时在app1中也加一个session，这样就不用老是跑到SSO去验证，能提高系统性能。 这样虽然提高了性能，那如果登出了。岂不是每个app都要清掉session？？ 是的，退出时要清除session，只是多了几句句代码而已。不是那么麻烦。 |
| 返回顶楼 | |
|
发表时间：2011-09-27
楼主的图用什么画的。。。
|
| 返回顶楼 | |
|
发表时间：2011-09-27
楼主的图用什么工具做的。。。 很炫啊，
|
| 返回顶楼 | |
|
发表时间：2011-09-27
可以单独的一个web来管理SSO，可以通过app1->sso 生成一个非对称加密的ticket，存到Map<user,ticket>中，返回ticket存cookie中，类似于sessionid的作用...
MSN的SSO就是这么实现的。 |
| 返回顶楼 | |
