跳过元数据结束转到Metadata开始，因为Shibboleth是开发的，最多要求的功能之一是单个注销（SLO）。我们的列表充满了线程，表明此功能似乎并不容易。本文档是一种尝试收集和阐述SLO困难。
下面提出的问题不是可能发生的理论问题列表。其中一些开发人员在类似协议中具有SLO实现的经验，并经历了所有这些问题或大多数问题。此外，Shibboleth团队已收到从测试匈牙利SLO插件的网站的报告，并且他们也遇到了这些问题。
在开始查看SLO周围的问题之前，请简要说明大多数Web应用程序如何跟踪他们的会话以及SAML 2 SLO中的消息流。
基于Web的大多数基于Web的应用程序存储关于内存中当前活动用户的数据，并使用随机生成的数字索引此数据集合：会话ID。此会话ID通常存储在浏览器cookie中，因此每次用户返回cookie时，都会向应用程序呈现，并且应用程序可以找到相关的，当前，会话数据。
SAML 2 SLO可以由身份提供者（IDP）或服务提供商（SP）启动。 SAML 2 SLO请求包含：指示要记录的名称，可选择地对应于初始身份验证语句中的可选属性的会话索引。 SAML 2 SLO响应包含一个状态URI，指示Logout操作是否成功。
SLO消息流如下。注意，SLO启动器有责任为用户提供有关SLO是否已成功或失败的信息。
在IDP处，用户已认证的每个SP：SP尝试销毁用户的会话，并发送退出响应，指示这是否成功
（如果sp-beative），IDP向发起服务提供商发送注销响应，然后销毁其会话
SAML 2定义了两种传输这些信息的广泛手段;通过HTTP POST或REDIRECT的浏览器，称为前通道绑定，或通过Direct IDP / SP SOAP消息，称为反向通道绑定。
为了使SLO成功，必须从用户体验方面满足几个要求：
用户必须明白它们目前已登录到单个登录（SSO）系统，并且单击“注销”按钮/链接将导致的内容。
用户必须始终知道注销是否完全成功。否则他们可能会假设它拥有并留下计算机允许其他人错误地访问服务。
SLO的第一个问题之一是与用户通信，如果他们点击＆＃34;注销＆＃34;用户已经被教导，执行此操作将导致它们从包含它们使用的注销按钮/链接的应用程序中注销。他们假设所有其他应用程序将保持活跃。因此，必须有一些方法可以区分应用程序级注销和SLO。
通常通过在所有参与应用程序中提供一致的UI组件来解决此问题。 MS Passport，Virginia Tech＆＃39; S authportal等系统，通过将品牌，不同的图像/按钮放置到应用程序级注销链路/按钮来完成此操作。当用户访问参与SSO系统的站点时，应用程序显示一个形式的UI组件，该表单指示用户可以登录。当用户登录到UI组件以反映这种状态。
然而，这种方法遭受了两个问题。首先，它需要教育用户有关此UI组件以及传达的意图。其次，它要求所有SPS显示相同的UI组件。虽然第一个问题可以通过教育努力解决第二个问题实际上是站不住脚的。第三方SPS将其服务销售给许多组织，并且不太可能为每个组织协调不同的UI组件。它和＃39; S也非常不太可能所有组织和SPS都会在一个统一，UI组件上同意。
在SP启动的SLO期间发生另一个UI问题。在这种情况下，SPS有责任为用户提供最终指示，了解SLO的成功或失败。但是，SP从IDP返回的信息量非常有限;一个URI，它表示完全成功或指示过程中的某些故障的URI。在SLO失败的情况下，SP将具有很少的信息，以便定制它向用户显示的内容，因为它不会知道失败的原因。在几乎所有的故障情况下，明智的事情就是告诉用户关闭他们的浏览器。这提供了一种处理这个问题的方法，但它不是很优雅。
如果使用前通道绑定，则此问题可能会变得更糟。如果SP没有响应，用户将以HTTP错误呈现。此时，IDP也不是SP向用户提供信息。一些SLO实现尝试通过使用帧来解决此问题。如果正确实施，这可以帮助改善问题。
在SLO期间，可访问性出现在两个地方。首先是上述注销UI组件。大多数网站似乎使用了一个图像。这对视觉受损的人带来了问题。解决方案非常简单;使用一个良好的，描述性的alt标签。大多数网站似乎都没有这样做。
如前所述，通常用于处理HTTP错误的机制，在使用前通道绑定期间可能发生的是帧。然而，大多数可访问性专家发现帧的使用是不可接受的，因为呈现出各种损伤的个人界面的难度（或不可能）。大多数Web浏览器意味着帮助这些人无法渲染各种类型的帧。
一个问题，已经讨论了在使用前频道绑定期间遇到HTTP错误时向用户传送信息。但是，还存在相关的技术问题。当IDP使用前通道绑定发送消息时，它将完全控制到SP（它希望在那里捕获它）。如果SP没有响应，则过程中断，剩余的SP不会接收注销请求。因此，除了无法告诉用户发生了什么，还有SPS，带有活动会话，这是不知道发生了失败的注销尝试。
前通道绑定的原因是使用户＆＃39; s浏览器，其会话cookie显示在应用程序中。然而，单个注销的一个用例是管理员强迫另一个用户的停止＆＃39; s会话（例如，他们的帐户已经受到损害，因为用户正在做坏事等）。在这种情况下，它将是管理员＆＃39; s浏览器，而不是用户＆＃39; s，这将访问服务提供商，从而防止应用程序访问会话cookie并将其销毁它作为使会话无效的手段。稍后提供用于解决此方法的手段。
返回通道绑定的使用可以减轻到目前为止所呈现的所有问题（除了SP-Beliated Rogout期间SLO响应中的失败信息缺失）。但是，就像在绑定用户绑定的前沟道上的管理注销的情况下一样，应用程序的会话cookie不可用，因此存在相同的问题;无法查看用户＆＃39; s会话并摧毁它。
最后，有问题是SAML 2支持单个注销。如果仅支持SAML 1的任何实体参与SSO会话，则将遗留退出过程。试图向用户解释哪些服务支持SLO，并且不太可能成功。
通过单一注销提出的最终问题是谁可能启动注销的问题。有些组织涉及允许第三方应用程序启动注销。这些问题中的大多数都是植根于目前用于传达用户参与SSO会话的差的机制，＆＃34;注销＆＃34;将在所有应用程序中摧毁他们的会话。
一个例子如下。学生访问大学＆＃39; S学生信息系统，参与SSO服务。学生要注册课程并正在审查可能的课程。在此评论过程中，学生访问库中的一些材料，该库也参与SSO会话，看看相关的类是否是所需的。因为他们被教授要始终在注销的应用程序中，他们单击库应用程序中的注销链接。此链接实际上是一个启用SLO的链接，并在学生信息系统中销毁会话。
因此，有些组织希望限制谁可以将单个注销启动到其控制下的一组应用程序。然后出现一个问题;如果用户只登录到组织外控制的应用程序，您会怎么做？用户要么需要教导某些应用程序只能在某些情况下启动注销，或者如果使用某些应用程序（第三方），则它们必须关闭浏览器而不是使用注销机制。许多用户不太可能理解任何一个消息。
当呈现这些问题时，许多人提供了一个协议，只有启动SP和IDP通信。目标是摧毁SP＆＃39; S会话和IDP＆＃39; s会话，以便如果他们再次访问该SP，用户必须重新验证用户。这种方法使所有其他SP会话都处于激活状态并准确地与用户通信，并且没有被退出。因此，这种方法增加了用户可能会使计算机与活动会话放弃计算机并允许意外，并且可能恶意，用户访问这些服务的风险。
要使它闲出，任何将尝试这种方法的应用程序只是为了自己忽视了参与参与SSO系统的所有其他应用程序的安全性的成本。
Web应用程序开发人员应该在使用Shibboleth时支持两件东西以支持单个注销。最简单的是删除所有应用级会话管理，并仅依赖于Shibboleth SP＆＃39; S会话管理。除了获得SLO支持外，修改后的应用程序将立即获得新的会话相关功能，因为它们被添加到Shibboleth产品中，并消除如果应用程序＆＃39; s会话与shibboleth的配置不同可能发生的任何混淆SP配置（例如，不同的会话超时）。
不依赖Shibboleth SP会话管理的Web应用程序需要通过SPIB-SESS-ID标头中的SP提供的SHIBBORETH会话ID索引他们的会话。然后，他们必须实现一个回调脚本，它将在SP接收到注销请求时调用，这将被销毁用户＆＃39; s会话。但请注意，应用程序不得假设传入请求承载会话cookie，并且必须考虑到脚本。
总之，SLO围绕使用的问题通常属于用户体验问题或技术问题。如果组织愿意在教育其用户的努力（这需要持续的努力以赶上新人），则可以解决许多用户体验问题。如果在使用前通道绑定期间发生HTTP错误，则无法应答当也会满足访问前频道绑定时，用户体验和相关技术问题。因此，后信绑定最有可能成功，但使用需要Web应用程序采取上述先决条件的步骤，许多开发商表示不愿意承诺的工作。这将使许多组织处于Impasse，在解决方案之间选择具有不安全或强迫开发人员的解决方案，以更改整个组织的应用程序。
一个找到php示例注销代码wiki页面关于shibboleth nativespnotify。此代码可用于实现Web应用程序的注销。
阅读并理解上述后，您可以深入呼吸并尝试将SLO的第三方实现到Shibboleth Identity提供商。这由Niif（匈牙利）提供，不受互联网支持。此实施需要在官方发布中包含更彻底的审查。您可以通过在邮件列表中提供反馈（或提出问题）来帮助。
我不能强调它：你应该在做任何事情之前真正阅读这个页面和SLO文档。