将 SAML 响应从 Web 应用程序传递到 REST API 以进行身份​​验证？

Question

我们有一个使用REST API的Web 应用程序。REST API 基于 Loopback 并使用其内置的基于令牌的身份验证。对于 Web 应用程序，我们使用基于表单的 HTTPS 身份验证，因此用户必须输入他的用户名和密码，然后我们使用这些用户名和密码通过端点从 REST API 获取访问令牌。POST /users/login

我们的一位客户要求我们通过SAML 2.0和AD FS支持单点登录 (SSO)身份验证。

我们将 Web 应用程序配置为服务提供商（AD FS 中的依赖方）并设法为其支持 SSO。变化的部分是 Web App 和 REST API 之间的身份验证。现在的想法是将 Web App 和 REST API 配置为相同的依赖方，POST /users/saml-login并向 REST API添加新端点，以便 Web App 可以向该端点发送 SAML 响应并根据声明获取访问令牌在 SAML 响应中指定。其他一切都应该像以前一样工作。这是我想象的流程：

1. Web App 生成 SAML 请求并将用户重定向到 IdP 登录页面
2. 成功登录后，用户将通过 SAML 响应重定向回 Web 应用程序
3. Web 应用程序充当代理并将 SAML 响应重定向到POST /users/saml-login验证它的 REST API 端点 ( )
4. 如果 SAML 响应有效，则 API 根据声明返回访问令牌
5. Web 应用程序使用访问令牌与之前的 REST API 进行进一步通信

问题是：以这种方式实现基于 SAML 的 SSO 是否可以？您认为这种方法有任何问题或安全考虑吗？有没有其他选择？

我在网络上阅读了很多文章，并在 StackOverflow 上阅读了有关如何一起使用 SAML 和 REST API 的问题：

• 将 SAML 断言响应/安全上下文传播到下游服务/应用程序
• 使用 SAML 的 REST API 身份验证
• SAML 和后端 REST 服务身份验证
• 攻击 SSO：常见的 SAML 漏洞和查找方法

他们都没有真正帮助我确认或拒绝上述想法。

Answer 1

这听起来是一个合理的方法。我想不出任何安全问题。您只需在应用程序内部重新发布 SAML 响应进行处理即可。只要您随后在 REST API 中对 SAML 响应和断言执行各种安全检查，就不应该出现任何问题。