咨询基于开源IdP实现SAML2多租户认证转发代理的方案

这个架构模式的标准名称是 SAML IdP Proxy（SAML身份提供商代理），也常被称作SAML联邦桥、多IdP路由代理，核心逻辑是代理层同时承担两个角色：对上游业务应用来说它是合法的SAML2 IdP，对下游各个租户的自有IdP来说它是SAML2 SP，负责完成认证路由、协议转换、断言字段映射的工作，和你描述的场景完全匹配。

• Keycloak：是实现该场景成本最低的成熟方案，原生支持该能力。
  你只需要把现有单IdP配置的业务应用对接为Keycloak的SAML客户端，再将每个租户的自有IdP逐一配置为Keycloak的上游SAML身份源即可。路由逻辑可以直接通过Keycloak的扩展能力实现：既可以自定义登录页增加租户名输入项，根据用户输入自动跳转对应租户IdP；也可以实现基于用户邮箱域名、租户专属访问链接的自动路由，无需用户手动输入。认证完成后Keycloak会自动完成下游断言到上游SAML断言的格式转换、字段映射，自带会话管理、权限控制能力，基本不需要额外开发大量定制代码。
• SimpleSAMLphp：可以实现，适合有PHP技术栈的团队。
  SimpleSAMLphp原生支持同时以IdP、SP双模式运行，你可以部署一套对业务应用提供服务的IdP端点，再将所有租户IdP配置为该实例对接的上游SP身份源，通过自带的认证流程过滤钩子，插入租户选择页面逻辑，根据用户选择的租户路由到对应上游IdP完成认证，再将返回的用户属性转换为自身IdP的断言返回给业务应用即可。缺点是多租户路由、租户选择页没有现成的开箱能力，需要自行编写少量业务逻辑代码。
• Shibboleth IdP：支持，但配置复杂度最高。
  Shibboleth本身为跨机构学术联邦场景设计，原生支持多上游身份源对接，你可以通过扩展认证拦截流程、配置IdP发现规则实现租户路由，但整体配置门槛高，定制开发量大于前两个方案，更适合已经在运维Shibboleth联邦体系的团队选用。
• 轻量专用选项：如果不需要完整IdP的用户管理、权限控制能力，只是单纯做SAML代理转发，可以选用专门的协议代理组件SATOSA，天生为多协议、多上游身份源代理场景设计，配置量远小于全功能IdP，非常适配纯代理转发的需求。

[业务应用App] -----> [自建IdP代理] ---------------------> [租户A自有IdP]
                              \
                               \----------------------> [租户B自有IdP]
                                \
                                 \--------------------> [租户C自有IdP]

代理核心执行流程：
1. 接收业务应用发起的SAML2认证请求
2. 向访问用户展示租户名称输入/选择界面
3. 根据用户提交的租户信息匹配对应租户IdP，转发认证请求
4. 接收租户IdP返回的认证结果，完成字段映射后，以代理自身IdP的身份将认证结果返回给业务应用

内容的提问来源于stack exchange，提问作者SNJ