|
锁定老帖子 主题：单点登录设计
精华帖 (1) :: 良好帖 (0) :: 新手帖 (3) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-09-27
jiangnan2112 写道 上两周要给两个系统做单点登录，别人建议我用cookie实现，后来我一了解情况发现两个系统其实是一个系统，只是分成了两个应用，他们会发布在一个tomcat下，如果是这样，就不需要cookie了，直接设置共享session来实现这个功能。现在这个方案已经被用到系统中去了而且暂时没问题，只碰到一个问题是这样的，取到共享的session后，因为设置了过期时间，共享session其实已经过期，但就是不知道如何来决断这个过期的状态，调试状态是可以看到一个isValid的属性为false了，但是没有找着相关的方法把这个值取出来，tomcat是调用了一个isValid()的方法来取这个值，但这个方法是tomcat的包中才有的，我用java没取出来，也没多余的时间去研究tomcat的源码，所以只好通过发生的超期的异常来判断共享session已经过期。
具体的实现是登录控制器再加一个过滤器，两个系统均一样。下面是当初画的简单的图： controller控制器： 
过滤器： 
退出登录： 
我当然知道不能移植，所有我前面的个前提，说明了情况，具体情况要看个人需求，我这两个东西是不会用两个tomcat的才这么做的，而且也只是用一段时间，这是我的前提。 |
| 返回顶楼 | |
|
发表时间：2011-09-27
Hypnusds 写道 用memcached 做 session
多方便 多谢指点，我会了解一下 |
| 返回顶楼 | |
|
发表时间：2011-09-27
zhyxfancy 写道 lz的sso的局限性很明显，首先是不是在一个tomcat，然后就是移植到其他应用服务器咋办。还有一点就是推出的时候，你只清空了commonsession和自身的session，那么另外一个系统的session还存在，没有实现一个站点退出全退出的sso原则。其实最好还是cookie实现，然后结合https，rsa非对称加密，账号是一个公司的根本，安全问题也是你需要考虑的，你可以使用cas，当然你也可以参照cas实现自己的sso。
兄弟确实指出了根本性的问题。其他的实现方案也是考虑过的，不过因为我的系统本身有点特殊，对安全性方面不是很高，而且用最多半年，也是最快的速度做出来我才采取了简单的方法，当然不能通用推荐，只是想交流一下这方面的知识而已。当然要清空别一个session也是可以做的，类似qq提示qq退出是否退出音乐一样，只是后来想想也实在没这个必要就从简了。 |
| 返回顶楼 | |
|
发表时间：2011-09-27
Jclick 写道 fantasy 写道 可以使用独立的单点登录应用ssoApp来做，这样可扩展性和安全性会更好。
1：用户访问App1的某个URL，App1通过cookie（必须加密）去单点登录服务器验证当前用户是否已经登录，如果没有登录，则跳转到单点登录应用的登录页面，并传递用户访问的URL。 2：用户提交用户名和密码，单点登录应用验证登录成功后跳转回App1,并传递token和sign(用于防止token被篡改)。 3：App1将返回的token和sign通过接口去单点登录应用进行验证，如果验证成功跳转用户访问的URL,并写入登录成功的cookie。 4：用户退出App1，清空登录验证的cookie。 那么即使新增一个app2或app3，照样可以支持单点登录。 你说的这种主要指的是在登录框的单点登录，但是如果需求的是登入一个系统，然后通过这个系统直接跳转到另一个系统的话，有没有很好的想法？ 我会再考虑一下看看，我现在是在每个系统登录后直接点点另一个系统就行了，是跳转的。 |
| 返回顶楼 | |
|
发表时间：2011-09-27
ironpearl 写道 minghuibo 写道 seesion的有效时间是可以设定的，一旦过期，就失效了，服务器端就找不到这个session了！也就是说你session.getAttribute()取到的是为NULL的，你可以通过这个区判断，lz的系统是公用一个session，那么一旦失效，就等重新登录了！
建议使用COOKIE 这样可移植性高 同时在app1中也加一个session，这样就不用老是跑到SSO去验证，能提高系统性能。 这样虽然提高了性能，那如果登出了。岂不是每个app都要清掉session？？ 我前提断断的是本身的session,如果本身的session已经过期，录然要重新登录。 |
| 返回顶楼 | |
|
发表时间：2011-09-27
过期后session.getAttribute()当然不能运行，session已经失效何来取属性。
|
| 返回顶楼 | |
|
发表时间：2011-09-27
最后修改：2011-09-27
sagahl 写道 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也是可以有单点登录服务器的。 综合来看，你对各种免登的方案知道的太少，张冠李戴，并且没有抓住各种免登方案的核心设计思想。 1. CAS 本身对于client 和 server 端通信采用的是 CAS1.0 或 CAS2.0 协议，但是我不赞同你说 CAS 本身就是一个协议。 2. 我说你才是 张冠李戴，我什么时候说了单点登录器就一定是 CAS 了啊？我只说上面说的就是CAS的实现方案而已。另外，对于 SSO 实现确实有很多方案，但是，重要的是看场合。 你觉得银行或企业内部的系统会用 oauth 实现 SSO 吗？为什么 google 或 新浪已经实现了完全实现了SSO，还要弄出一个 Oauth 或 openid 出来呢？ 另外，你说了 p3p sso， P3P只是用于一种跨域访问和设置 cookie 的方案，只是用于解决 SSO 中对于 cookie 跨全域的一个解决方案而已，离真正的 SSO 还远着呢？ |
| 返回顶楼 | |
|
发表时间：2011-09-27
最后修改：2011-09-27
sagahl 写道 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设计，如果你有兴趣，我们可以交流一下。 首先，客户端应用系统 保存 ST 登录凭证有什么用呀？ST 对于一个client应用系统 来说只能使用一次，只要进行使用 st 对系统进行访问授权之后, st 就已经失效了, 且只有在第一次访问应用系统时ST才有用。一看你就是对 cas 不了解，还在这里说扯他的流程。 引用 但是协议本身有很多限制，也不符合大家的使用情况
CAS 提供了 openid、restful、smal 等之类的公共认证或授权协议，你居然说协议本身有很多限制。 引用 我对sso了解不多，大概只研究了3年左右，
都最少工作三年了来在拿年限说事？见过搞 JAVA 5年和搞JAVA 2年的人技术含量差别不大的情况多的是。 引用 有幸参与过某些银行系统的面等及国际较大电子商务网站的sso或OPEN API设计
说这些没用，起码发个你做过产品的URL或写出两篇文章出来让我好"膜拜"一下。好歹也要对得起你那三年的”研究“成果嘛 |
| 返回顶楼 | |
|
发表时间：2011-09-27
我只是实现一个小功能，也是发贴的初衷，没想到大家总是把问题高度化，实现功能的方法有很多，每一种都有优缺点，针对目前的我项目，我的实现方法是基本上是最好的了，因为各人情况都不一样，难道你非要让我用ldap去实现，说那样有什么好处什么好处，那我不直接去例如ibm买一个产品喽。大家可以探讨但不要太激烈和带有攻击性的最好了。
|
| 返回顶楼 | |
|
发表时间：2011-09-27
SAML,以前用这个搞过一个SSO，不过比较复杂！
|
| 返回顶楼 | |
