PingFederate 无代理 SLO 序列

Question

我正在尝试在 PingFederate 的无代理（参考 ID 适配器）方案下在我的应用程序中实现 SLO 支持。对于登录、链接和会话，有一个下车和上车顺序。是否需要在注销请求时删除注销详细信息？如果是这样，数据的预期结构是什么？

Answer 1

我搞砸了。重要时刻。我很抱歉。

我去玩了一些，它很有效，非常不同。我们将更新我们的文档，因为它应该在那里。在短期内，我们将发布一篇知识库文章，但它尚未通过审批工作流程。所以...与此同时...这是我的大量编辑。

---

SP 无代理适配器单次注销 (SLO)

SP端的SLO流程与IDP的SLO流程类似，只是在pickup的过程中返回的属性不同，销毁的是用户本地应用的session而不是认证流程的session。

以下步骤适用于前置通道 SLO。在反向通道场景中，PingFederate 将使用您在查询字符串中定义的任何属性调用注销页面。然后，您可以使用从 PingFederate 传递的值终止会话。

例如，如果会话根据断言的主题维护在数据库中，要使用反向通道注销，我可以修改 PingFederate 配置以指定反向通道注销并将注销服务端点设置为包括“ ?subject=${subject}” 附加到 SLO 网址。

然后应用程序需要获取这个“主题”查询参数（与它在前通道 SLO 中接收的“REF”参数相反）并终止相应的应用程序会话。

SLO 进程启动

在前通道 SLO 活动期间，将向 IDP 适配器配置中定义的“注销服务端点”发出请求。此请求将包含 SLO 端点的“REF”参数，用于检索有关请求注销的会话的属性。

HTTP Response
HTTP/1.1 302 Found
Headers
Content-Type:   text/html;charset=UTF-8
Location:   https://app.company.com/signout?REF=PPQQRRSSTTUUVVWWXXYYZZ11223344
Body
<N/A>

第 1 步 – 获取 REF 属性

当收到 SLO 请求时，必须检索此 REF 参数并将其用于获取有关请求注销的会话的属性。该值将在以下步骤中称为 [REF_VALUE]，并使用“PPQQRRSSTTUUVVWWXXYYZZ11223344”的值填充。

第 2 步 - 获取有关注销的信息

与 SSO 请求类似，适配器将向拾取端点发出 HTTP GET 请求以检索有关注销的属性：

HTTP Request
GET https://pf.company.com:9031/ext/ref/pickup?REF=PPQQRRSSTTUUVVWWXXYYZZ11223344 HTTP/1.1
Headers
Authorization:  BASIC YXBwX3VzZXI6YXBwX3Bhc3N3b3Jk
ping.instanceId:    app
Body
<N/A>

响应将包含有关请求注销的会话的信息。

HTTP Response
HTTP/1.1 200 OK
Headers
<N/A>
Body
{
"resumePath":"\/sp\/pCyCo\/resume\/sp\/SLO.ping",
"sessionid":"sFMcTOaropYv5gYQZi1ZOpX7DZ8"
}

响应中将返回以下属性：

属性 - 描述 resumePath - 在本地注销过程结束时发送给用户以继续 SLO 活动的 URL。
sessionid - PingFederate 用于跟踪经过身份验证的会话的 sessionid。这将与拾取 SSO 属性时收到的值相同。

第 3 步 – 销毁本地应用程序会话

SLO 页面将解析这些属性并销毁本地会话（即删除会话 cookie）并执行与属性对应的任何注销处理。 （即如果会话在数据库中维护了一行，应用程序可以使用提供的 sessionid 删除这些行并结束会话）。

在返回的属性中还有 resumePath 值，在销毁会话后，下一步需要重定向用户。这将被称为 [RESUME_PATH] 值，并将包含从上述响应中检索到的值 /sp/pCyCo/resume/sp/SLO.ping。

第 4 步 – 将用户返回到 PingFederate

要继续 SLO 流程，用户必须返回到第 3 步中收集的 [RESUME_PATH]。还必须在此 URL 上提供恢复请求的来源，并作为“来源”查询参数附加。所以使用以下变量：

·[PINGFEDERATE_SERVER] 来自配置的值
·第3步收集的[RESUME_PATH]值
·配置中的[ADAPTER_INSTANCE_ID]值

利用这三个组件，我们可以使用以下格式创建完整的简历 URL：

[PINGFEDERATE_SERVER] + [RESUME_PATH] + ?source= + [ADAPTER_INSTANCE_ID]

这会导致以下重定向：

HTTP Response
HTTP/1.1 302 Found
Headers
Content-Type: text/html;charset=UTF-8
Location: https://pf.company.com:9031/sp/pCyCo/resume/sp/SLO.ping?source=app
Body
<N/A>

本地应用程序注销过程现已完成，用户将继续 SLO 活动。

错误处理

与 IDP 场景类似，在处理来自 PingFederate 的接送请求期间的任何错误都将作为 HTTP 状态代码返回。例如，如果指定了错误的客户 ID 或密码，那么在取货/还车过程中将返回 401 HTTP 错误。

应用程序只会收到来自先前已通过身份验证的用户的登录请求。在身份验证过程中收到的任何错误都应使用应用程序品牌进行适当处理。用户可能已经在 IDP 完成了身份验证过程。

注意：错误屏幕应位于受保护内容之外。当用户在登录或授权阶段收到错误时，他们需要能够查看错误，而不是通过身份验证过程发回。

---

顺便说一句...虽然 SLO 肯定是 SAML 的一部分...我认为这是一团糟 - 特别是当您有不参与的大型组织（如 SFDC 和 Google）时。我在上面写了blog post。