为了实现SSO，我一直在和一些IdP和一个Shibboleth SP安装，但是没有能够回答这个问题。
在IdP方面，我有几个元数据文件来描述一些应用程序。 这些文件可以包含一个证书，但如果没有提供，通信工作仍然良好。 如果我把相同的文件放在SP端，即使把一些随机字符当作证书，它仍然可以正常工作。
有人能真正向我解释这些元数据文件（IdP）方面的X509证书是如何工作的？
这些证书是信任的锚点。 它们允许您validation签名，并因此build立对已交换消息的信任。 （这与在浏览器中configuration的可信CA证书非常相似，用于validationHTTPS站点的证书。）
SAML请求和响应应该被签名（至less是响应）。 您可以find<ds:DigestMethod /> ， <ds:DigestValue />和<ds:SignatureValue />等元素（但如果使用HTTPredirect绑定，则可能会简化）。
当SP通过浏览器从IdP获得SAML响应时，它必须validation它获得的签名来自它知道的IdP以及使用IdP的私钥签名的内容; 可以根据元数据中configuration的证书中的IdP公钥validation此签名。
对于一个SP来说，如果没有这样做，整个过程将变得毫无价值，并且能够在不validationIdP消息的真实性的情况下接受任何断言，这意味着configuration错误。
在IdP方面，一个学位不太重要。 如果IdP希望validation请求确实来自它所信任的SP，则这是唯一必要的。 如果SP请求披露某些机密属性（并非所有的SP都应该看到），并且可能对响应中的这些属性进行encryption，以便只有这个SP才能读取它，这就特别有用。
这就是说，Shibboleth可以通过一个反向通道（属性服务）释放这些属性，SP和IdP之间的连接是直接build立的（没有与浏览器的消息交换）。 SP和IdP之间的身份validation应该仍然发生在这个事件中，但是我认为它可能在传输级别上工作（例如客户端证书authentication），而不是消息级别（通过SAML签名），我不确定。 无论哪种方式，你也需要为此设置信任锚。
这些证书是为了确保在idp和sp之间交换的数据是：
这些协议的安全function在部署生产系统时不应忽略。
在作为联盟的一部分的系统中，实际使用x509证书（它们是强制性的）。
X509证书包含用于公钥encryption的密钥，IdP密钥可用于从IdP签名消息或将消息encryption到IdP或两者（尽pipe通常不会将消息encryption到IdP）。
看看这个堆栈溢出问题的签名和encryption之间的区别： https : //stackoverflow.com/questions/454048/what-is-the-difference-between-encrypting-and-signing-in-asymmetric-encryption
查看Shibboleth文档中有关在元数据中使用键的示例： https ： //wiki.shibboleth.net/confluence/display/SHIB2/MetadataKeyDescriptor
密钥是否实际用于签名或encryption取决于在IdP和SP之间传递的消息的configuration文件。 也就是说，消息是SAML1还是SAML2格式，以及使用哪个端点。