【今日话题】 单点登录系统设计 （Api 方式 和 Web 方式） 1. api方式，用户每次登录都分配一个sig，设置这个sig的过期时间，通过用户uid和sig来获取数据 web方式更简单，session直接存redis 当然这都是小打小闹，坐等大牛分享 是单点登录呀，[撇嘴]我错了 - smarteng 2. 不管哪个，主要的还是token验证吧 - 老猫是我 3. 单点登录 http://blog.csdn.net/lifetragedy/article/details/43817903 - 周围 4. 我目前的设想是，共享认证的身份令牌 token 身份令牌只能在 登录系统中才能获得，而且这个身份令牌必须在所有涉及的系统中均能识别。 - 猿蜗 5. 我司用openid - Daniel 6. p3p cookie的方案呢 不用联网 完全通过cookie交互 cookie使用rsa加密 大家都有对方公钥 - Nemo 7. cas是单点登录的一种实现，用于一个企业的多个系统整合，方便登录，不用登录了一个系统再登录另外一个系统，前题要保证多套系统用户一致。oauth是开放授权的，主要是为了第三方的应用使用中心化的用户 - 田亚乐 8. 如何一个应用登陆其它都可以自动登录 比如一个论坛我想用我自己的用户而不要系统那套 这样的用oauth好些吧 自己的那个也无法直接访问数据库 - tony 9. [擦汗]，自己的还不能访问，如果能提供单点登录，是比较适合的，但是论坛需要做单点登录的开发 - 田亚乐 10. LDAP - Huangsir 11. 基于Cookie的SSO登录分析和实现 http://www.cnblogs.com/chenpingzhao/p/4940024.html - 踏雪无痕 12. 单点登录我说点简单自己的看法。 在web时代会比较麻烦一些，如果多域名设计到跨域之类的问题。一般跨域解决方案都是嵌入一个iframe，然后每个iframe都会种一个cookie到浏览器，或者是在登陆的时候多个域名都会操作一下cookie。 api方式简单些，因为cookie之类的都是客户端（app）来自己处理，而且域名不域名的不重要，只要app本身能够读取信息就行了，一般也是类似于种cookie的方式写入到app的sqlite数据库，然后校验登陆的时候把相关cookie信息同步给服务端。 app端有个稍微麻烦点的是第三方登陆，比如需要微博、微信、qq等第三方登陆，需要在自己系统做一个相关绑定，注册一个隐形账号之类的，稍微麻烦些。 - 黑夜路人 13. 可以用P3P让客户端自己去子站种 也还可以在服务器端用信任授权来做～ 另外也有用授权后把用户跳来跳去做的 我感觉还是要看具体业务场景和用来认证的账户中心是自己的还是第三方的 OAuth2 也有三种模式～我记得… - 大饼 14. app里登录，在客户端存储一个PHP SESSION id类似的加密串，里面包含用户的登录状态，如用户id，登录时间等信息，用着方便 - 风之缘 15. add_header Access-Control-Allow-Origin *; 用这个解决跨域。 - 念念念恩他爹 回: @念念念恩他爹这是近年来可以选择的一种方式 适用于自己的多域名子站 - 大饼 回: 是的 而且很方便。但有些浏览器不支持 - yongsean 16. 单点登录，用ajax也可以吧。各个业务都向passport请求，获取状态。 - 沙漠风暴 17. 单点用cas，其他也没用过 - 耿安鹏 18. http://blog.csdn.net/cutesource/article/details/5838693 单点登录SSO的实现原理 - 猿蜗 19. 你们好像说的是多业务自动登录 我觉得就是不用那么复杂，结合SSO，当前系统判断用户是否在本系统登录，如果没登录，跳去passport做下登录验证就是了 反正就是两个302的事情 小白用户更不不会有多大的感觉不一样 然后我们来说下SSO passport的实现 也是简单粗暴就行 用户在passport登录后。302带token到业务系统。业务系统服务器拿着token 到passport验证 然后就完了[呲牙] - 李刚 20. 补充一下，用ldap存储用户信息。 - simon 21. session共享也是一个方案。当然的看业务场景。- @理鱼 22. 登录态就业务系统自己保存啊 各自喜欢怎么保存都行 当然。passport也要保持自己的 第二个系统跳过来验证登录的时候 不用显示登录框了， 直接就带着token 302到业务系统了 - 李刚 23. sso之前我也做了一下，主是要参考cas协议，然后使用数据签名来保证安全性 权限的设计是用微服务的方式提供接品，将权限分为 读, 写，查看这样的行为，每个应用可以创建模块，并指定用户或组是否有指定的行为，最终用户要进行某一类操作的时候，程序要调用接口看当前用户是否有对这个模块权限 - 张建 24. App其实简单，他是黑盒，别人看不到算法，所以自己生成加密token，但是浏览器端麻烦些 - tiyee 25. 比如说你在公司内网。有好几个内部系统。比如财务系统。预约系统。内部运营系统等等。如果每次都要登陆就很麻烦。体验也不好。这时候就需要单点登陆 这块我的经验只有默默的给一个token。每次需要登陆的时候先验证token。如果没有或者超时才需要登陆 - 熊mao 26. 以前自己简单实现是一处登录以后，往所有域名 加 加密cookie（web） - smile 27. token需要加上:版本号,token类别(例如大中小三个),用户唯一识别码, 腾讯以前的这种老师被吐槽.所以他们后面开发出大中小,三种票据.都是大票可以换小票;不同操作需要不同的票据 - pengVin 28. 公司内网，你可以把cookie种在顶级域名下，其他各个系统使用2级域名去读就可以了，这个很容易做 如果各个顶级域名不同的，可以使用上述说的嵌套iframe的方式来做 大多的场景来说，基本都是在同一个顶级域名里面共享session，所以基本还是问题不大的。如果涉及到不是同一个顶级域名的，一般来说都是第三方的，可以用oauth 你写一个passport.xxx.com，然后把cookie种在xxx.com，各个子系统，比如finance.xxx.com，可用xxx.com的cookie来完成身份的识别，cookie统一在passport.xxx.com处进行校验 - 廖强 29. token在app比较容易，但是浏览器不安全，要oauth 强总方法不安全 不灵活 - tiyee 30. 确实有安全方面的风险，因为有一个子系统因为安全问题导致了cookie的泄漏，会对其他系统的用户信息造成损害 - 廖强 31. 对，简单是这样，通过引用一个登陆域名的资源，获取cookie - tiyee 32. 互联网上有多个子站点的，都可以看看流程的，firebug就足够了，比如sohu oauth严格来讲不算是单点登录吧 - 可乐 33. 淘宝上好像就是，强哥说的那样 在各个系统上，种上认证网站的cookie 这种最简单好用 - 踏雪无痕 34. 可以针对不同安全级别的系统 种不同访问控制的cookie，又要单点 又要绝对安全，没有 oauth跟单点登录没半毛钱关系 - 唐毅 35. 嗯，安全性的考虑得基于业务场景，比如支付宝就不是很信任淘宝的session 支付宝的安全级别要求，比淘宝高很多 - 廖强 36. 也可以在每个项目页面，先判断登陆，没登陆就跳到登陆页面，再反弹回来 - tiyee 37. 单点登录只是实现了，登录，更安全控制的控制不在sso做吧 sso的主要作用就是用来识别用户，其他，各个子业务可以自己控制 - 可乐 38. 安全控制在sso也可以做，但都是一些普适的，比如，非常用地登陆，密码输错次数等 单点登录后续关联的，主要是两个方面，一个是安全，一个是权限控制 单点登录我倒是觉得问题不大，网上资料也挺多的，但是权限控制的设计，就比较有意思了，看大家的抽象度如何了，做一个灵活的权限控制 - 廖强 39. https://en.m.wikipedia.org/wiki/Single_sign-on 先看看完再来讨论 SSO和session/cookie共享是两码事 前着是目的，后着只能作为一类手段 - 沐旦 40. 群里讨论的，也没说这两者是一回事，也是讨论如何实现这个目的，不冲突啊 最开始有几个人在解释sso，也就是解释了这个事情的目的。这个也是很明确的 - 廖强 41. 单点登陆，就是子系统登陆时请求单点服务，返回认证信息，子系统根据认证信息各自写自己的cookie。退出时再通知单点服务，清理认证和cookie 单点会遇到跨域的问题，设置一下header就可以了 - Glon 42. 单点登录可以把自己要用的不同顶级域名在授权服务器绑定一个二级域名调用指定页面写入授权cookie - 阿飞 43. 共享cookie的问题很多，但确实挺实用，可用于相同业务，但不同业务，就不太推荐使用了 oauth可用于第三方应用鉴权，也能用于SSO，国内很多大学的SSO很多使用了OAuth1.0a - 沐旦 【分享链接】 1. 深度 | 为了古老的中国围棋，谷歌和Facebook正展开激烈的算法竞赛 https://mp.weixin.qq.com/s?__biz=MzA3MzI4MjgzMw== |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
