SP 发起的 SAML SSO 的实际流程，包括所有组件，即 IDP、SP 客户端和 SP 服务器端

问题描述

我使用 keycloak 作为 IDP，jersey rest services 作为后端和 angular UI 作为前端，其中我的后端和前端是单独的应用程序在相同的 tomcat 服务器上运行。

我在互联网上找到的每个示例都使用完整的后端来支持 SP 发起的 SAML SSO。我不明白前端贡献在哪里或前端如何受到保护。

当我们谈论 open id SSO 协议时，我发现用户代理调用前端应用程序，该应用程序将用户重定向到 IDP 并获取代码并将其传递给后端。后端负责所有令牌的验证。

所以我有一些问题

1. 如果我们有前端应用程序，SAML 中的流程是否与开放 ID 相同？
2. 前端应用程序能否生成 SAML 请求并将用户重定向到 IDP？
3. 身份验证成功后，IDP 重定向到后端还是前端？
4. 如何保护服务以及在哪里验证 SAML 断言？

解决方法

Is the flow in SAML same as open id if we have a frontend application?

或多或少。用户转到前端应用程序，因为他们没有与应用程序的有效会话而被拒绝访问。

Can frontend application produce SAML request and redirect user to the IDP?

是的。它需要创建一个包含 AuthNRequest 的 SAMLRequest 并将其发布到 SP。

身份验证成功后，IDP 重定向到后端或 前端？

或多或少。 IdP 首先检查元数据中的 SP 属性消费者服务 (ACS) url。如果不匹配，则拒绝向 SP 发送 SAMLResponse。

How are services protected and where is the SAML assertion validated?

这取决于SP。如果用户在应用程序中没有有效会话，则需要将他们重定向到 IdP，并且应用程序必须验证 SAMLResponse 并根据该响应中的属性为用户创建有效会话。

验证是通过 SAML 元数据中包含的 X509 证书完成的。不过这东西很复杂。