我在配置了多个身份提供商的应用中实施Spring SAML。我的IdP元数据配置包含多个ExtendedMetadataDelegate和HTTPMetadataProvider以及每个IdP的别名。该应用选择以与this类似的方式扩展SAMLContextProvider，以选择要使用的提供商。
当IdP发送授权时，我的应用需要知道它来自哪个IdP（不同的提供商具有不同的安全授权）。我正在docs建议这样做，并使用自定义SAMLUserDetailsService和SAMLCredential.getRemoteEntityID()来确定哪个IdP发出了请求。
我的问题是，我可以依赖remoteEntityID来识别提供商吗？如果一个IdP提供商更新其元数据以包含不同的实体ID甚至＆＃34;伪造＆＃34; entityID与其他提供商相同？使用我们定义的对等别名不是更好吗？
我是SAML的新手，所以我很可能对某些基本概念的理解不正确，我只是想确保我没有使用此配置打开安全漏洞。
答案 0 :(得分：0)
这是一个很好的问题。我不知道答案所以我试了一下。
我在我的测试环境中有一个MS ADFS和SpringSAML项目的实例，其中配置了一个服务提供者和身份提供者（用于ADFS）。在我的自定义SAMLUserDetailsService中，我使用SAMLCredential.getRemoteEntityID()来确定请求来自哪个IDP。
我成功登录，然后更改了ADFS EntityID的名称，然后再次尝试登录。这导致日志中出现AuthNResponse; SUCCESS; 127.0.0.1消息，但浏览器出错。我在UserDetailService中启用了调试后再次运行它，发现请求在到达UserDetailService之前失败了，但是，我没有在日志中看到任何错误消息。
为了回答你的问题，（也许其他人可以更明确地回答），SpringSAML会适当地处理这种情况，因为它会出错。它并不是因为日志中没有错误消息。我认为这是因为它发生了一些不寻常的情况，或者只是一个错误。
就伪造另一个身份提供商的实体ID而言，SAML请求已签名，因此任何尝试伪造和IDP消息的人都必须能够访问其私钥。
最后，别名不在请求中，因此不能用于区分IDP。