|
锁定老帖子 主题：单点登录设计
精华帖 (1) :: 良好帖 (0) :: 新手帖 (3) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-09-27
求画图工具！
|
| 返回顶楼 | |
|
发表时间：2011-09-28
denger 写道 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或写出两篇文章出来让我好"膜拜"一下。好歹也要对得起你那三年的”研究“成果嘛 CAS的ST是一次性的，我没有说请求验证方hold住ST，而是验证方hold住ST验证成功后颁发给B的凭证（可能是cookies），但这个行为和CAS系统一点关系都没有。很多系统不适合于使用CAS，关键问题就在于跳转，比如淘宝中大量使用的Mashup页面，SAAS系统等等，总的说来是CAS太重。另从CAS协议设计的原始版本中，建议是使用一页一验证的方式（早期的交行网银网页版），完全不需要应用自己颁发凭证，只是我们为了方便而形成现有的使用只验证一次然后自己颁发凭证的模式而已（alibaba中文站）。不是说提供了多种协议的支持就一定没有没有很多限制，我说的协议限制你自己去好好考虑一下，我没有时间和你多解释。 看你说话就知道你很臭屁，什么人都瞧不起。你也没有明白我的意思乱喷，和泼妇骂街没有什么区别。我在上一家公司的平台技术部做了几年的免登的研究和session服务化的专职研究，我不需要给你看我做过的产品向你来证明什么。我现在是无业游民一个。我资质有限，也许我研究2年顶不上您几个天研究。我本着与人交流的态度，既然你不是一个好的交流者，我多浪费口水也没有意义，祝你以后的技术更上一层楼。 |
| 返回顶楼 | |
|
发表时间：2011-09-28
zistrong 写道 SAML,以前用这个搞过一个SSO，不过比较复杂！
呵呵，以前也用过SAML，实在是流汗呀。产品出来后没有人愿意用，太复杂。后来改为Oauth1，后来客户还是觉得麻烦，就升级为Oauth2 |
| 返回顶楼 | |
|
发表时间：2011-09-28
denger 写道 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 还远着呢？ 看掉了一篇回帖，最后给你说说。CAS不是协议是什么？难道是一个开源框架？CAS1.0和2.0不就是针对于不同的应用场景的免登流程标准吗？难道官方的文档我看错了？还有client和server端之间传输的是CAS1.0和CAS2.0协议，佩服你的理解能力。 还有企业内部为什么不会使用Oauth实现SSO，多的是，特别是公司大了后，内部系统分主干系统和分支系统的时候，Oauth有大用的。 google有多种免登系统，有历史原因，也有扩展的需要，google本身也是用过CAS，但现在以Oath，AuthSub，ClientLogin，auth gadgets等等等等。正不说明了CAS的局限性？既然按照你的说法，CAS提供了多种协议的兼容那为什么google为什么还要这么多麻烦？ P3P协议和P3P SSO 系统是一样的东西吗？CAS也是基于Token机制的，ASO是基于信道对称加密机制的，难道Token==CAS？应用你的一句话：你“离真正的 SSO 还远着呢” |
| 返回顶楼 | |
|
发表时间：2011-09-28
sagahl 写道 denger 写道 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 还远着呢？ 看掉了一篇回帖，最后给你说说。CAS不是协议是什么？难道是一个开源框架？CAS1.0和2.0不就是针对于不同的应用场景的免登流程标准吗？难道官方的文档我看错了？还有client和server端之间传输的是CAS1.0和CAS2.0协议，佩服你的理解能力。 还有企业内部为什么不会使用Oauth实现SSO，多的是，特别是公司大了后，内部系统分主干系统和分支系统的时候，Oauth有大用的。 google有多种免登系统，有历史原因，也有扩展的需要，google本身也是用过CAS，但现在以Oath，AuthSub，ClientLogin，auth gadgets等等等等。正不说明了CAS的局限性？既然按照你的说法，CAS提供了多种协议的兼容那为什么google为什么还要这么多麻烦？ P3P协议和P3P SSO 系统是一样的东西吗？CAS也是基于Token机制的，ASO是基于信道对称加密机制的，难道Token==CAS？应用你的一句话：你“离真正的 SSO 还远着呢” 引用 看掉了一篇回帖，最后给你说说。CAS不是协议是什么？难道是一个开源框架？CAS1.0和2.0不就是针对于不同的应用场景的免登流程标准吗？难道官方的文档我看错了？还有client和server端之间传输的是CAS1.0和CAS2.0协议，佩服你的理解能力。
麻烦你好好看看：https://wiki.jasig.org/display/CASUM/CAS 其它的懒的跟你扯了～ 就此打住 |
| 返回顶楼 | |
|
发表时间：2011-10-02
fantasy 写道 可以使用独立的单点登录应用ssoApp来做，这样可扩展性和安全性会更好。
1：用户访问App1的某个URL，App1通过cookie（必须加密）去单点登录服务器验证当前用户是否已经登录，如果没有登录，则跳转到单点登录应用的登录页面，并传递用户访问的URL。 2：用户提交用户名和密码，单点登录应用验证登录成功后跳转回App1,并传递token和sign(用于防止token被篡改)。 3：App1将返回的token和sign通过接口去单点登录应用进行验证，如果验证成功跳转用户访问的URL,并写入登录成功的cookie。 4：用户退出App1，清空登录验证的cookie。 那么即使新增一个app2或app3，照样可以支持单点登录。 思路很好，有具体的例子吗？ |
| 返回顶楼 | |
|
发表时间：2012-01-18
 目前我们公司的项目也是用共享seesion 做的，本想做一个单点登录，后来想想时间紧迫，就直接上共享seesion 了。后期需要的话再改了。
|
| 返回顶楼 | |
|
发表时间：2012-01-18
初始可以考试数据库存储sessionid的方式来共享信息
后期卡率采用memcahched之类的缓存来保存共享session 目前我们一个项目采用的是第一种方式，因为还不使用memchached |
| 返回顶楼 | |
|
发表时间：2012-01-18
天一 写道 楼主的图用什么画的。。。
引用 只关心楼主的流图是用神马画的。
|
| 返回顶楼 | |
|
发表时间：2012-01-18
共享session不可取。
你没看到很多网站都有"用新浪微博登陆"，“"用QQ微博登陆"”吗？ 搜一下OpenId，很成熟的技术了。 |
| 返回顶楼 | |
