在几个网站透明的用户会话(单点登录+单签收)(Transparent user session ov

2019-06-24 03:30发布

我在不同领域的几个网站: example.comexample.orgmail.example.compassport.example.org 。 所有的网站都具有共同的外观和感觉,并应共享相同的用户群。

在这种极端情况下我还是希望所有的网站,以透明 (尽可能)共享用户会话具有以下主要特性:

  1. 单点登录 。 当在用户登录passport.example.org和访问任何其他网站-他应该被视为登录。

    登录的用户得到“你好, $username “问候现场标题和不同的导航菜单,列出的服务,他们有机会获得。 如果他不签署,而不是问候有一个“登录”链接,指向passport.example.org/signon

    信任域的列表是已知的,所以这是非常简单的实现或者使用OpenID或一些homebrewn轻量级协议。 当用户第一次点击该网站,我重定向他以特殊的身份验证端点passport.example.org ,然后静静地重定向他回去,身份信息(或匿名身份“未签署”)包括在内。 对于大多数浏览器,这是完全透明的。 很显然,我使用的随机数的值打重定向循环。

  2. 一次性注销 。 在接下来的时间,他访问任何网站,任何网站的标题。当用户点击“搁笔” - 他应该被视为“未签署”。

    OpenID的不是为这一点。 我现在的想法(我已经有部分工作的实现)是在DB不发送用户身份,但“全局”会话令牌和共享全局会话表(global_session_token↔用户关系)。

  3. 机器人和cookie的用户支持 。 网站是有公共区域,这应该是由用户代理访问没有任何cookie支持。

    正因为如此,重定向我在(1)项成为一个问题,因为对于每一个页面请求,我将最终抛出的用户代理要权威性端点和背部。 这不仅会混淆的机器人,但它会污染我的会话数据库死在出生的会议非常快。 我绝对不希望显示“哎,你不启用Cookie,走开!”的页面,那会是非常无礼的行为令人失望。 当我需要支持cookie登录,我希望用户能够自由地读什么网站是等等 - 没有任何限制。

    而且我明确不想把URL中的会话ID,除了我刚才提到了一些透明的跨域重定向。 我相信这样做是一个安全问题,只是一般是坏事。

    在这里,我几乎没了主意。

好吧,我知道这很难,但谷歌实际上这是否在某种程度上( google.comgoogle. 很多-的-通用顶级域名gmail.com等等),对不对? 所以这应该是可能的。

我会为任一协议描述的想法感激(这会是最好的)或系统链路(或者代码阅读或者只是活的网站观看和学习后)已经成功地实施这样的事情。

概括起来:若干域而不公共根,共享的用户群,单点登录,单点登录关,无需cookies来匿名浏览。

所有站点都在同一个网络上(但停留在不同的服务器)和部分共享相同的PostgreSQL数据库(在同一个数据库的不同方案休息)。 大多数网站都使用Python编写/ Django的,但他们中的一些使用PHP和Ruby on Rails。 虽然我在想的东西和框架 - 语言无关,我为指向任何实现感激。 即使我将不能使用的话,我就会懂了它是如何做有可能我就可以拿出实施类似的东西。

Answer 1:

好了,让我解释了一下,然后进一步。 (所有URL都是虚构的!)正如我所说的,游客去http://www.yourwebpage.com ,并表示他希望登录,他将被重定向到。 http://your.loginpage.org?return=http: //www.yourwebpage.com/Authenticated在那里,他将不得不提供他的用户名和密码。
当他的账户信息有效,他将返回到在登录网址提供的网页,但与将用作ID的附加参数。 于是,他去http://www.yourwebpage.com/Authenticated?ID=SharedSecret其中SharedSecret将是一个临时的ID,有效期为30秒或更少。
当你的认证页面被调用时,页面会然后调用,将其之间yourwebpage.com和loginpage.org共同寻找SharedSecret的账户信息检索更永久ID的方法。 这个永久ID被存储在yourwebpage.com的网络会话以及不应该被显示给用户。
共享方法可以是任何东西。 如果两个服务器在同一台机器上,他们可能只是上访问同一个数据库。 否则,他们可能会通过Web服务的另一台服务器通信。 这将是服务器到服务器的通信因此,如果用户是机器人还是没有cookie支持也没关系。 这部分将不会被用户注意到。
你必须应对的唯一的事情就是该用户的会话。 通常情况下,用户将被送到一个储存在cookie中的会话ID,但它也可以是URL的一部分,作为一个GET请求的一部分。 这是更安全了一下,有一个POST请求中的会话ID,但是,通过添加隐藏的输入字段到表单中。

幸运的是,一些Web开发语言都已经提供会话支持,所以你甚至不必担心维护会话,发送会话ID的。 该技术是有趣的,但。 而你需要知道会话应该永远是暂时的,因为有一个风险,即会话ID的阻挠。

如果你要处理不同域上的多个站点,那么你就需要先在一些服务器到服务器的通信工作。 最简单的是通过让他们共享同一个数据库,但它更好地构建Web服务解决这个数据库,用于额外的保护。 确保这个Web服务只接受来自您自己的域名的请求只是为了增加更多的甚至有点保护。
当你有服务器到服务器的连接,那么用户将能够将您的域之间只要你沿着一个会话ID传递到新的领域,用户将登录切换。如果用户是使用饼干,这是不太可能的会话丢失这将需要重新登录。 如果没有Cookie,有一个机会,用户将不得不重新登录获取新的Cookie,如果会话ID被浏览的网页之间丢失。 (例如,参观者前往参观谷歌,然后返回到你的网站。用一个cookie,会话可以从cookie中读取。没有Cookie,因为谷歌的会话丢失,将无法通过会话ID转发。

请记住,传递会话ID的不同域之间是存在安全隐患。 会话ID可被劫持,从而有可能为别人冒充您的访客。 因此,会话ID的应该是短暂的,模糊的。 但是,即使黑客获得访问会话ID,他仍然没有完全进入到帐户本身。 他将无法拦截服务器到服务器的通信,所以他不能与您的用户信息访问数据库,除非他直接进入登录页面。



Answer 2:

据我所知,谷歌只是使用了“Google.com”域的cookie。 但谷歌也使用OpenID它允许一个通用的登录机制。 基本上,这是通过重定向你到一个特殊的登录页面。 这个登录页面会发现,如果你已经登录与否,如果你没有登录,它会要求你登录。否则,它只是重定向你直接到下一个页面。

所以,在你的情况下,用户会打开somepage.example.com和这个应用程序会话中没有登录ID。 因此,将用户重定向到logon.example.biz当用户登录。这背后,页面也将是一个会话和会话会告诉用户已经登录(还是不行,在这种情况下,用户必须首先登录。)然后重定向哪里这个会话ID将被存储在somepage.example.com的会话的用户somepage.example.com?sessionid=something。 然后,本次会议还将知道用户已登录并为它几乎似乎是透明的用户。

在现实中,用户被重定向两次。



Answer 3:

您是否使用ASP.NET? 如果是这样,你可能想看看enableCrossAppRedirects财产。



Answer 4:

对于此解决方案无需护照服务器。

登入

  1. 登录
  2. 用加密的会话ID和其他信息创建令牌
  3. 从你的域上的设置Cookie显示与令牌IMG。

授权由饼干

  1. 你已经对所有域的cookie。

登出

  1. 清除饼干
  2. 销毁会话
  3. 在DB上届会议ID关系明确的用户ID(我想你保存会话ID在用户表由饼干上升会话)

我不能尝试此解决方案。 但现在我有同样的问题,因为你(SSO)和我尝试这个明天。



Answer 5:

如果所有的应用程序都在一个域,那么它是不是太困难,因为你可以使用域级别cookie来处理会话控制。 (cookie的会话管理是困难的,但可以做到的,但很困难。)

但是,您表示对example.com域一些网站,有的在example.org域。

打了一下我的谷歌叹息式,和其他网站他们的orkut.com,它看起来就像当你打,需要证书的页面,它重定向你的帐号登录,然后重定向你回到原来的公共网站现场,想必传递某种会话令牌中的URL。 由此看来,想必orkut.com服务器与google.com服务器来验证令牌和得到任何其他用户信息,需要直接协商。

更多信息在域级别的Cookie作为Reqeusted

如果您有两个网站,说foo.example.combar.example.com,您可以设置具体到主机的饼干,但你也可以设置一个cookie用于将由域上的所有主机上看到的域。

因此, foo.example.com可以设置一个cookie foo.example.com具体而言,它会只把自己看到的,但它也可以设置域饼干example.com,而当用户去bar.example.com他们也会看到这第二个cookie。

但是,如果你也有一个网站, snafu.example.org,不能看到这个域级别的cookie foo设置,因为example.orgexample.com是两个完全不同的领域。

您可以使用域级别cookie来保持在同一个域中跨站点的会话信息。

如何设置域级别的Cookie取决于你的开发环境(我有轨,对不起没有经验)。



Answer 6:

我已经使用陈词滥调,对于SSO方案和联合身份,但我认为你需要的是,上述更简单的解决方案。



Answer 7:

跨域能够Rails插件做这将是真棒。

我想做到这一点,我能想到的唯一办法是强制用户下载一个工具栏,或者一些小的空气应用程序,将处理自动为我登录。

我很想知道另一种方式“的原因在于打击



文章来源: Transparent user session over several sites (single sign-on + single sign-off)