为了实现 SSO，我一直在使用一些 IdP 和 Shibboleth SP 安装，但无法回答这个问题。
在 IdP 端，我有一些描述某些应用程序的元数据文件。这些文件可以包含证书，但如果没有提供任何内容，通信仍然正常。如果我将相同的文件放在 SP 端，即使将一些随机字符作为证书，它仍然可以正常工作。
有人能向我解释一下它究竟是如何工作的，以及那些元数据文件（IdP）中的 X509 证书的用途是什么吗？
答案1
这些证书是信任锚。它们允许您验证签名，从而建立对已交换消息的信任。（这与浏览器中配置的用于验证 HTTPS 站点证书的受信任 CA 证书非常相似。）
SAML 请求和响应应该签名（至少响应应该签名）。您会发现诸如<ds:DigestMethod />、<ds:DigestValue />和 之类的元素<ds:SignatureValue />（尽管如果您使用 HTTP 重定向绑定，这可能会简化）。
当 SP 通过浏览器从 IdP 获取 SAML 响应时，它必须验证所获取的签名是否来自其认识的 IdP，以及是否使用 IdP 的私钥进行签名；可以根据元数据中配置的证书中的 IdP 的公钥来验证此签名。
对于 SP 来说，不这样做会使整个过程变得毫无价值，并且在没有验证 IdP 消息的真实性的情况下接受任何断言表明配置错误。
在 IdP 方面，它在某种程度上不那么重要。只有当 IdP 希望验证请求是否确实来自其信任的 SP 时，它才是必要的。如果 SP 请求披露某些机密属性（并非所有 SP 都应看到），并且可能在响应中加密这些属性，以便只有此 SP 可以读取它，则它特别有用。
话虽如此，Shibboleth 可以通过反向通道（属性服务）发布这些属性，SP 和 IdP 之间直接建立连接（无需与浏览器交换消息）。在这种情况下，SP 和 IdP 之间的身份验证仍应进行，但我认为它可能在传输级别（例如客户端证书身份验证）而不是消息级别（通过 SAML 签名）上起作用，我不确定。无论哪种方式，您还需要为此设置信任锚。
答案2
这些证书是为了确保 idp 和 sp 之间交换的数据：
- 避免被窃听
- 是从你认为向你发送消息的来源发出的
- 消息是防篡改的，没有人在传输过程中对其进行修改
这些是协议的安全特性，在部署生产系统时不应忽略。
在作为联合一部分的系统中，实际上使用了 x509 证书（它们是强制性的）。
答案3
X509 证书包含公钥加密的密钥，而 IdP 密钥可用于对来自 IdP 的消息进行签名或对发送给 IdP 的消息进行加密，或者两者兼而有之（尽管通常不会对发送给 IdP 的消息进行加密）。
看一下这个堆栈溢出问题，了解签名和加密之间的区别：https://stackoverflow.com/questions/454048/非对称加密中加密和签名之间的区别是什么
请参阅 Shibboleth 文档，了解在元数据中使用键的示例：https://wiki.shibboleth.net/confluence/display/CONCEPT/MetadataKeyDescriptor
密钥是否实际用于签名或加密取决于 IdP 和 SP 之间传递的消息的配置文件。也就是说，消息是 SAML1 格式还是 SAML2 格式，以及使用哪个端点。