使用SAML扩展和Shibboleth在Spring中进行单一登录
我想在基于Spring的应用程序中实现单点登录（SSO）身份验证层，以支持来自不同安全域的身份验证和授权。我选择了Shibboleth作为IdP，但我尚未确定我将用于SP的内容。
选择是：
扩展：组件使新应用程序和现有应用程序都可以充当基于SAML 2.0协议的联盟中的服务提供者，并启用Web Single Sign-On。Spring Security Extension允许在单个应用程序中无缝组合SAML 2.0和其他身份验证和联合机制。可以使用在身份提供者模式下支持SAML 2.0的所有产品（例如ADFS 2.0，Shibboleth，OpenAM / OpenSSO，RM5 IdM或Ping Federate）来连接Spring Security SAML Extension。
（也称为SP）：Shibboleth是一项基于Web的技术，可实现SAML的HTTP / POST，工件和属性推送配置文件，包括身份提供商（IdP）和服务提供商（SP）组件。
因此，我有一些问题：
- 就可伸缩性和可维护性而言，直接使用Spring SAML作为SP是个好主意吗？
- 可以将外部SP与Spring Security一起使用吗？如何配置我的应用程序和/或我的应用程序服务器（JBoss 8.0-WildFly）？
- 我在哪里定义角色（针对每种情况）？
- 哪个值得选择？
最好的问候，V.
回答：
两者之间的主要区别是部署方案：
插件直接部署到Apache / IIS Web服务器。
嵌入在您的应用程序中。
两者都有优点和缺点。
- 就可伸缩性和可维护性而言，直接使用Spring SAML作为SP是个好主意吗？
- 可以很好地控制身份验证的执行方式以及身份验证过程与应用程序的交互方式。您可以例如创建自己的配置UI并动态添加IDP，创建自定义登录屏幕作为应用程序的一部分，可以完全轻松地控制错误处理，轻松支持多个IDP，动态配置SSO的详细信息（请求的AuthnContext，NameID，绑定） ，强制验证）。
- 轻松解析各种格式的接收到的SAML属性，在同一应用程序中支持多种身份验证方法。
动态生成SP元数据，它提供有限的多租户并支持所有其他选项（例如，单一注销，密钥持有人，IDP发现）中不可用的配置文件。
- 与Spring Security无缝交互，带来了自己的一系列好处。借助Spring SAML，您还可以直接在应用程序中配置完整的身份验证和授权策略（例如，哪些页面是否需要身份验证以及何时，基于角色的内容访问控制，动态条件下的身份验证，等等）。
- 允许您将应用程序部署在任何应用程序服务器或容器上以及任何反向代理服务器或Web服务器之后，而不会影响功能。
- 这些是静态配置的，通常通过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插件。
以上是 使用SAML扩展和Shibboleth在Spring中进行单一登录 的全部内容， 来源链接： utcz.com/qa/401737.html
