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

Question

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

我在互联网上找到的每个例子都使用SP启动的SAML SSO的完整后端。不明白frontend在哪里做贡献或者frontend是怎么保护的？

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

所以我有一些问题

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

Answer 1

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证书完成的。不过这是复杂的事情。