【问题标题】:auto logout from second application when logout trigger from first application从第一个应用程序注销时自动从第二个应用程序注销
【发布时间】:2015-02-09 05:35:26
【问题描述】:

场景:

我有两个使用 pingfederate 单点登录服务登录的应用程序。

1.用户尝试登录到第一个应用程序,但由于用户未经身份验证,用户被重定向到 pingfederate 的登录页面(通用登录页面)。用户登录到第一个应用程序。
2.用户尝试登录第二个应用程序,因为用户已经通过单点签名服务 pingfederate 的身份验证,为应用程序提供必要的信息(设置会话所需的信息),用户被重定向到第二个应用程序。

问题:
当用户从第一个应用程序注销时,用户成功注销。此时 pingfederate 知道所有打开的应用程序并发送然后注销回调。因此它将注销请求发送到第二个应用程序。第二个应用程序处理注销请求并清除会话。但是用户停留在同一页面上。用户未重定向到登录页面

问:
当我们收到注销请求时,如何实现将用户重定向到登录页面?

【问题讨论】:

    标签: ruby-on-rails logout long-polling pingfederate


    【解决方案1】:

    SLO 应该为 SP-Init SLO 工作的方式是:

    1. 您在 FIRST SP 应用程序中单击注销。

    2. 您被重定向到带有 LogoutRequest 的 IdP。

    3. 然后 IdP 将您连续发送到所有其他 SP 注销请求。每一个都必须返回一个 SAMLResponse 到具有状态的 IdP。

    4. IdP 在收到最终状态后,必须发送 用户/浏览器通过 SAMLResponse 与 SP 采取行动的最终状态。

    在 IdP-Init SLO 中,基本上只有第 3 步。

    不过,这是关键所在,我认为这是您问题的核心。如果其中一个 SP 的“行为不端”,即不响应或不支持 SLO(不需要他们支持 SLO),那么如果您重定向到它,它将破坏注销的“链” ! IdP 将重定向到 SP,并且浏览器将停留在那里。链条一旦断了,就没有办法重新开始了。

    一年多以前,我在我的博文"SLO - Proceed With Caution" 中讨论了这个问题。最终,由于许多大牌 SP 不支持 SLO,没有太多理由这样做 - 作为 SAML 管理员,它只会给你一个黑眼圈。或者胃灼热。或两者兼而有之。

    【讨论】:

    • 我得到了这个工作流程。同样的事情也发生在这里。我的问题不是关于我触发注销的第一个应用程序。我说的是第二次申请。我看到第二个应用程序服务器记录它收到来自 ping federate 的注销请求。它清除会话,然后使用给定的“Resume”参数重定向到 ping federate SP,但此重定向不会显示在浏览器上。对于用户来说,他看起来仍然在同一页面上。
    • 这将取决于 SP 应用程序 - 那里的日志中有任何内容吗?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2019-09-20
    • 2016-02-07
    • 1970-01-01
    • 1970-01-01
    • 2011-07-27
    • 2019-04-01
    • 1970-01-01
    相关资源
    最近更新 更多