我搞砸了。大时代。我很抱歉。

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

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

SP侧的SLO进程与IDP SLO进程类似,但在拾取过程中会返回不同的属性,用户本地应用程序会话将被销毁,而不是身份验证进程会话。

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

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

然后,应用程序需要获取这个主题查询参数(与它在前通道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-sessionid PingFederate用于跟踪经过身份验证的会话。这将与拾取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]+?源=+[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和谷歌)不参与时。我写了一篇 blog post 在上面。