在 Jersey 和 Spring SAML 安全 SSO 验证之后路由到 Angular 组件

Posted 2023-02-27

【中文标题】在 Jersey 和 Spring SAML 安全 SSO 验证之后路由到 Angular 组件

【英文标题】：Routing to Angular component after Jersey & Spring SAML Security SSO Validation

【发布时间】：2021-09-12 06:11:14

【问题描述】：

我正在开发一个应用程序，它使用 Angular 作为前端和 Jersey 与 Spring SAML Security 集成以进行 SSO 身份验证。

我尝试从 Angular (http://localhost:4200) 调用应用程序，该应用程序将调用对 Jersey 项目的 API 调用，这将返回一个 URL（与泽西服务器相关的 URL）来访问服务器以显示 IDP 登录页面。登录 IDP 后，它会将我路由回服务器，从这里我想将响应重定向到 Angular 以显示主屏幕。

在下面的 Angular 组件中使用，它将使用 (https://localhost/saml/login) 击中 Jersey

window.location.href =  samlObject.url;

登录完成后，我登陆https://localhost/loginComplete，必须路由到http://localhost:4200/home

请提出任何可能的解决方案。

【参考方案1】：

当您访问您的站点时 - GET 调用 http://localhost:4200 -> 本地网络服务器响应 Angular 的 index.html，然后执行捆绑的 js 并决定显示什么。使用您的身份验证机制捆绑 Angular 的 js 代码实现身份验证丢失，根据您在那里编写的后备计划，它重定向到 IDP（在您向服务器询问 IDP 的 url 之间）。 （所有这些过程都发生在浏览器中。） 点击 auth - GET 调用 IDP 的登录名（现在您要离开 Angular 应用程序并显示 IDP 的前端）。发布您的凭据并登录（IDP 的前端调用 IDP 的后端并登录）。 （所有这些都发生在您的浏览器中）然后 （这里我猜您注册了一个属于您的后端的 post auth 重定向 url。）这会对您的后端进行 GET 调用。如果您的休息控制器有响应，那么它将显示在您的浏览器中。

现在...

谁实际登录了？用户

谁代表您的用户？前端 -> 角度

后台登录了吗？没有

后端是否代表任何人？没有

每个用户的后端。任何授权的 api 调用都意味着后端将临时代表该用户（在 auth 中指定的内容）。当 API 调用结束时，后端停止动作。

纠正您的流程。您需要在登录后重定向到您的前端。因此，当您向 IDP 注册您的应用程序时，重定向 url 必须是您的前端路由。此 url 可以是在您的 Angular 应用程序中具有路由的组件。类似 http://localhost:4200/login

对于 OAuth SAML 流程，我们会收到一个临时的 - 在前端仅使用一次身份验证码。 我们会将其提供给后端并要求将其转换为访问令牌、id 令牌、刷新令牌等。然后取决于您，您可以查看 id 令牌（解析 JWT）并将新的用户信息再次打包到 JWT 中。您可以通过将其作为对传递 authcode 的 api 调用的响应将其返回给 angular。

但是...近年来发生了很多变化。

现在 SPA 被视为一个应用程序，但不安全（哈哈）

所以有一个最佳实践指南：https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-13

---

简答：从 IDP 重定向到您的 Angular 应用程序，而不是您的后端

---

学习更大的 OAuth 2.0 总是一个好主意。这将涵盖 SAML 流程 + 很多其他内容。有了它，您也可以了解其他系统中的 SAML 流实现。这是一种痛苦，但你被社区所覆盖。 https://github.com/manfredsteyer/angular-oauth2-oidc 确实是 Angular 的救星。

【讨论】：

感谢您的清晰解释。此流程的问题是，我们希望使用 Angular 无法处理 POST 请求的 POST 请求将 SAML 响应发送到 Angular 应用程序。此外，Angular 没有合适的插件来托管使用批准用于生产的服务。

始终将 Angular 或其他 SPA 视为附有一堆 js 的静态 html 页面。不可能是服务。即使您从 Angular 到 IDP 进行延迟轮询呼叫，还有其他问题，例如您如何知道呼叫者是通过身份验证的人。这正是 OAuth 2.0 使用一次性身份验证码的原因，您可能必须采用相同的方式。