PingFederate 与多合作伙伴的 SLO 问题
我正在使用 PF 5.2.0 设置 IdP 和多个 SP。我的问题是关于单一注销场景。
如果 SP1 和 SP2 已与我的 IdP 建立了会话，则在 IdP 启动注销时，通过向两个 SP 发出 samlp:LogoutRequest 可以正常工作。如果在与 IdP 建立会话后其中一个 SP 关闭，则 SLO 无法完成，这意味着如果 SP1 关闭，则假设第一个注销请求发送到关闭的 SP1，则 samlp:LogoutRequest 不会发送到 SP2。
我正在使用 POST 绑定，但我相信这将是相同的重定向结果，并
等待您的评论..
-Vj
I am using PF 5.2.0 to setup an IdP and also multiple SP's. My question is about the single Logout senario.
if session has been established by SP1 and SP2 with my IdP then on IdP initiated logout it works fine by issuing samlp:LogoutRequest to both the SP's. Am facing an issue if one of SP's is down after establishing an session with the IdP then SLO does not complete, meaning if SP1 is down then samlp:LogoutRequest is not send to SP2 assuming the first logout request is sent to SP1 which is down.
I am using POST binding, but I believe this will be the same result for redirect as well
awaiting in anticipation for your comments..
-Vj
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Vj -
这是前通道 SAML 2.0 SLO 的“设计”行为，实际上与 PingFederate 没有任何特定关系。这也是您没有看到很多企业使用 SLO 的原因之一。
SAML2.0 SLO 的缺点之一是它可能非常脆弱。正如您所注意到的，如果任何 SP 未能向 IDP 返回响应，则整个事务将停止，因为 IDP 正在等待恢复事务。不幸的是，这正是前端通道 SAML 2.0 SLO 的工作原理。我相信基于 SOAP 的 SLO，由于浏览器从不涉及，因此不会有相同的限制。然而，这要求 SP 将用户的状态保存在数据库中，当它收到 SLO 请求时可以将其删除，而无需访问用户的浏览器 cookie 来删除会话（因为浏览器永远不会访问该会话） SP 在这种情况下）。
华泰
——伊恩
Vj -
This is "by design" behavior with front-channel SAML 2.0 SLO and really doesn't have anything specific to do with PingFederate. It's also one of the reasons you don't see many Enterprises using SLO.
One of the drawbacks of SAML2.0 SLO is that it can be very fragile. As you have noticed, if any of the SPs fail to return a response to the IDP, the entire transaction is stopped since the IDP is waiting to resume the transaction. Unfortunately, this is just how front-channel SAML 2.0 SLO works. I believe with SOAP-based SLO, since the browser is never involved, it does not have the same limitation. However, this requires the SP to keep the user's state in a database that can be removed when it receives the SLO request w/out the need to also get access to the user's browser cookies to remove the session (since the browser will never visit the SP in this scenario).
HTH
--Ian