两者之间的主要区别是部署方案：
Shibboleth SP插件直接部署到Apache / IIS Web服务器。
Spring SAML嵌入在您的应用程序中。
两者都有优点和缺点。
- 就可伸缩性和可维护性而言，直接使用Spring SAML作为SP是个好主意吗？
spring SAML
- 可以很好地控制身份验证的执行方式以及身份验证过程与应用程序的交互方式。您可以例如创建自己的配置UI并动态添加IDP，创建自定义登录屏幕作为应用程序的一部分，可以完全轻松地控制错误处理，轻松支持多个IDP，动态配置SSO的详细信息（请求的AuthnContext，NameID，绑定） ，强制验证）。
- 轻松解析各种格式的接收到的SAML属性，在同一应用程序中支持多种身份验证方法。
动态生成SP元数据，它提供有限的多租户并支持所有其他选项（例如，单一注销，密钥持有人，IDP发现）中不可用的配置文件。 - 与Spring Security无缝交互，带来了自己的一系列好处。借助Spring SAML，您还可以直接在应用程序中配置完整的身份验证和授权策略（例如，哪些页面是否需要身份验证以及何时，基于角色的内容访问控制，动态条件下的身份验证，等等）。
- 允许您将应用程序部署在任何应用程序服务器或容器上以及任何反向代理服务器或Web服务器之后，而不会影响功能。
Shibboleth插件
- 这些是静态配置的，通常通过HTTP标头与您的应用程序交互。它们使身份验证逻辑与应用程序本身脱钩，因此您唯一需要注意的就是接受标头和使用正确的安全上下文初始化应用程序会话。IIS / Apache服务器上基于URL模式提供了对哪些页面进行保护的定义，这意味着身份验证和授权策略部分在应用程序外部定义。
- 您需要确保只能通过Web服务器访问该应用程序（=禁止所有直接访问），因为这将允许伪造标题。
- 不需要对应用程序本身进行很多更改，因此通常可以轻松地与遗留系统一起使用。
可以将外部SP与Spring Security一起使用吗？如何配置我的应用程序和/或我的应用程序服务器（JBoss 8.0-WildFly）？
是的，有可能，但是需要付出努力。您可以例如配置WildFly以设置加密格式的共享域cookie，并在Spring Security配置中验证cookie。我在哪里定义角色（针对每种情况）？
使用Spring SAML，您可以在处理SAML响应时定义角色，例如通过解析SAML属性。这是通过实现SAMLUserDetailsService接口并将其插入来完成的samlAuthenticationProvider。
使用Shibboleth，您可以使用头将从IDP接收到的属性转发到您的应用程序，并在应用程序中解析它们。
WildFly（可能）使您可以直接在SP中定义安全性上下文和角色，而无需在应用程序中进行配置。这种配置可能无法跨应用程序服务器移植。
- 哪个值得选择？
所有选项将使您能够使用SAML 2.0执行WebSSO。人们通常根据需求（例如，定制需求），环境（使用的Web服务器，应用程序服务器），首选的开发方法（Java，.NET等），使用的框架，遗留代码进行选择。许多客户都使用Spring SAML和Shibboleth插件。
