为什么使用 x.509 证书来加密 xml？ 为什么不直接通过 https 传输呢？
对加密不太了解...
假设我正在准备提交给身份提供商的 SAML 请求。 为什么我需要为此请求应用 x.509 证书？ 仅通过 SSL 传输还不够安全吗？
Don't know much about encryption...
Say I'm preparing a SAML request to submit to an identity provider. Why would I need to apply an x.509 certificate to this request? Is transmission over SSL alone not secure enough?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
对于 SAML，消息级安全性（即 XML 本身经过签名，有时是加密的），因为通信涉及不直接通信的各方。 SSL/TLS 用于传输级安全，仅在直接通信的两方之间以及仅在该通信期间使用。
根据您使用的 SAML 绑定，该对话框可能如下所示（例如，沿着 Shibboleth 的行)：
在这种情况下，尽管涉及所有 3 方，但 SP 和 IdP 之间没有直接的 SSL/TLS 连接。 （这种情况的某些变体涉及 SP 和 IdP 之间针对属性的后端通信，但这是一个不同的问题。）
如果中间方（即用户）不打算查看 SAML 消息中的内容和/或用户与 SP 或 IdP 之间的连接不是通过 SSL/TLS 进行的，则适用于签名的内容也适用于加密（通常应该通过 HTTPS 进行）。
In the case of SAML, message-level security (i.e. the XML itself is signed and sometimes encrypted) because the communication involves parties that don't communicate directly. SSL/TLS is for transport-level security, only used between the two parties that are communicating directly and for the duration of this communication only.
Depending on which SAML binding you use, the dialog can look like this (e.g. along the lines of Shibboleth):
In this scenario, there is no direct SSL/TLS connection between the SP and the IdP, although all 3 parties are involved. (Some variants of this involve a back-end communication between SP and IdP for attributes, but that's a different problem.)
What applies to signing also applies to encryption, if the middle party, i.e. the user, isn't meant to see what's in the SAML message and/or if the connection between the user and the SP or IdP isn't over SSL/TLS (usually, it should be over HTTPS).
是的 - SSL 就足够了 - 但 SSL 只能是点对点的。 如果源计算机和目标计算机之间存在一些中介，则无法使用 SSL 保护连接。
在这种情况下，例如通过互联网传输时，您必须保护实际消息，而不是传输层。 这就是为什么您需要加密 XML（或至少是其中的一部分）。
马克
Yes - SSL is enough - but SSL is only point-to-point. You cannot secure your connection using SSL if there are a few intermediaries in the way between your source and your target machine.
In that case, e.g. when transmitting over the internet, you must safeguard the actual message, instead of the transport-level. That's why you need to encrypt the XML (or at least parts of it).
Marc
HTTPS 所做的只是加密两点之间的通信并防止窃听者 - 它不会确认发送消息的人是谁。 如果您的消息随后被转发，也无法保证安全通信。
如果您使用 X.509 证书签署您的请求，您可以放心解密者拥有证书中包含的共享秘密。 换句话说，您可以放心，该消息只能由您希望解密的组织解密。
就您而言，X.509 加密要求意味着您应该确信身份提供商是唯一会收到您的请求的组织。
有用的维基百科入门指南位于此处。
All that HTTPS will do is encrypt the communication between two points and prevent eavesdroppers -- it won't confirm who it was that sent the message. Neither will it assure secure communication if your message is then forwarded.
If you sign your request with the X.509 certificate you can be assured the decryptor has the shared secret contained in certificate. In other words, you can be assured the message can only be decrypted by the organisation you want it to be decrypted by.
In your case, the X.509 encryption requirement means that you should be assured that the identity provider is the only organisation that will receive your request.
A useful Wikipedia primer is here.
很可能是因为他们想验证您（客户）的身份。 HTTPS 可用于客户端身份验证，但在实践中很少。
Most likely because they want to authenticate you (the client). HTTPS can be used for client authentication, but it rarely is in practice.
实际上，您可以使用 HTTPS (SSL/TLS) 来保护您的 SAML 消息。 但是您可能希望使用双向 SSL 证书验证/确认，这意味着您的客户端需要验证服务器的 X.509 证书，并且服务器需要配置为执行客户端身份验证，这需要它检查 X.509 证书。客户端提供的 509 证书。 因此，无论如何，客户端都需要自己的证书。
SSL/TLS 并不是真正为此设计的...它的设计目的是为了保护网络流量在传输过程中不被看到，并且让客户端能够知道他们正在与哪个服务器通信并向哪个服务器发送敏感信息（它是真正为电子商务而设计，其中客户（购买商品的用户）知道他们将信用卡信息发送给谁）。 就 SAML 而言，重点是让各方知道他们正在交换的信息在传输过程中没有被更改，并且每个人都在与他们认为自己的身份进行对话。 使用证书来签署/加密该消息本身就可以实现这一点。
In practice, you could use HTTPS (SSL/TLS) to protect your SAML message. But you would want to use two-way SSL certificate verification/validation, meaning your client would need to verify the server's X.509 certificate and the server would need to be configured to perform client authentication, which would require it to check an X.509 certificate that the client presents. So, the client would need its own certificate anyway.
SSL/TLS is not really designed for this...it was/is designed to protect web traffic from being seen while in transport and for the client to be able to tell what server they are talking to and sending sensitive information to (it was really designed for e-commerce where the client (user buying something) knows who they are sending their credit card information to). In the case of SAML, the whole point is for the parties to know that the information they are exchanging has not been altered in transport and that each is talking to who they think they are. Using certificates to sign/encrypt that message itself accomplishes that.