Spring security 将SAML断言响应/安全上下文传播到下游服务/应用程序

我们的环境中有多种服务

在某些情况下，我们希望用户自动登录/静默登录到一个或多个参与服务，而不会在从一个服务首次成功登录后被身份提供商质疑凭据或与身份提供商通信

例如，我们有一个前端UI应用程序，希望使用SpringSecuritySAML对其进行身份验证。当UI应用程序与后端服务通信时，我们希望安全上下文/断言响应自动传播到后续服务调用

也许，被调用的服务/应用程序可以相应地验证断言响应，并允许访问其服务/应用程序，而无需让所有服务/应用程序在每次需要访问时直接与身份提供者通信

是否有一种方法可以将成功使用Identity provider进行身份验证后获得的SAML断言响应从一个应用程序/服务传播到正在从SAML验证的应用程序/服务调用的其他下游应用程序/服务

我尝试向Identity Provider注册2个应用程序，然后用IdP成功验证了一个应用程序，但无法从第一个应用程序成功访问另一个应用程序。当我使用Spring的RestTemplate点击服务时，我收到一条错误消息，如下所示

我不确定是否所有下游应用/服务都应该向IdP注册

在第一个应用程序成功通过Idp身份验证后，当它尝试调用另一个同样受Idp保护的应用程序时，我在第一个应用程序中收到如下错误消息

注意：由于您的浏览器不支持JavaScript，
必须按一次“继续”按钮才能继续。

让SAML用户Authn上下文传播的一个解决方案是使用IdP代理（链联合）

Okta IdP您的IdP代理您的SP应用程序

IdP代理是位于IdP和SP之间的SAML到SAML网关（如上所示）。IdP代理必须有一个SP组件（这样它才能与Okta IdP对话），还必须有一个IdP组件（这样它才能与您的SP应用程序对话）

您可以使用Okta IdP配置您的IdP代理，然后将N个SP应用配置到您的IdP代理，它可以直接与Okta IdP对话以验证用户身份。然后Okta将SAML断言发送给IdP代理，IdP代理验证它，生成特定于请求的SP应用的新SAML断言，并将该断言发送到请求的SP应用

---

查看更多信息。

我认为您正在寻找一种方法，让用户使用Okta IDP登录到任何应用程序，并能够导航到任何其他应用程序，而无需再次提示输入凭据。尝试将用于一个SP的断言发送到另一个SP将不起作用。已签名的SAML请求包括请求的来源和目的地。您必须禁用该部分安全性才能使其正常工作，这最终会危及应用程序的安全性

您可以使用SAML配置一个应用程序作为入口点。处理SAML部分，并且可以进行扩展 允许用户登录到其他应用程序，而无需通过将其与组合来提示输入凭据

这可以通过向您的域发送cookies来实现，cookies将包含在每个后续请求中。是一个无状态安全性的示例，它还使用cookie允许用户关闭选项卡，导航回应用程序并仍然登录。理论上，如果cookie发布正确，您可以将此行为扩展到多个应用程序，例如.*.example.com如果其他应用程序配置为使用相同的cookie，您应该看到的行为就是我认为您正在寻找的

---

希望这能有所帮助。

您的应用程序是在同一个域上还是在不同的域上？i、 e.app.company.com、app2.company.com或app.com app2.com？您的应用程序中是否使用无状态或基于会话的安全性？应用程序将位于同一域中。我们使用的是基于资源的服务，因此我们希望应用程序具有无状态安全性。@HelloUser我也遇到了类似的情况。您能告诉我们您决定采用哪种方法吗？谢谢您的建议。但是，就我而言，我只有一个IdP，可以与所有SP应用程序共享。IdP代理是否只有在连接多个IdP和多个SP时才有意义。此外，它是一个IdP不可知的解决方案，我的意思是它可以用于任何IdP以外的Okta。你能提供更多关于我如何在okta中使用IdP代理的详细信息吗。您共享的链接更多的是使用F5，但不确定在我的场景中是否需要此链接。是的，IdP代理可以配置多个IdP或单个IdP（如上所述）。此外，SAML是一种协议规范，它显然是不可知的，可以由任何公司实现，无论是Okta还是任何其他X公司。该链接仅供参考（现在我改为通用IdP代理示例）。我提出的答案是一个你可以考虑的解决方案。也可能有其他的解决方案。解决方案看起来逻辑正确，但听起来并不实际可行！考虑与同一IDP联合的多个系统。Web应用程序希望与SAP建立后端（非浏览器）连接。此处SAP已在同一IdP内注册为SP。为什么SAP会依赖另一个IdP（代理IdP）的断言？许多低代码平台提供现成的SAML连接器。这里没有进行更改的余地。@BhushanKarmarkar