WCF netTCP 绑定
WCF 的 netTCPBinding 是“默认安全的”。据我了解,这意味着..
- 调用者使用其 Windows 凭据进行身份验证。
- 消息经过签名
- 消息经过加密。
不过,我可以在本地主机上设置一个非常基本的 WCF 客户端服务。身份验证将像在同一台计算机上一样工作,但是签名和加密如何工作?
WCF 需要证书来签名和加密消息。如果我没有证书,那么我的服务如何运行?消息如何(即使只是发送到同一台机器)进行签名和加密。
谢谢。
WCF's netTCPBinding is "secured by default". As I understand it this means that..
- Callers are authenticated using their windows credentials.
- Messages are signed
- Messages are encrypted.
However, I can set up a very basic WCF client service set up on my localhost. The authentication will work as its on the same machine, but how does the signing and encryption work?
WCF needs a certificate to sign and encrypt messages. If I dont have a certificate then how does my service manage to work? How does the message - even just going to the same machine get signed and encrypted.
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
默认情况下,NetTcpBinding 使用传输安全性以及您列出的默认特征。
在此上下文中消息的签名和加密与消息安全中的含义不同。相反,它意味着通过网络传输发送的所有数据包都经过签名和加密。这不依赖于证书。它是由发送和接收计算机上操作系统中安装的安全提供程序完成的,通过 SSPI 调用 (安全支持提供程序接口) - 涉及相同的机制,例如,当使用域凭据访问某些资源(例如网络上不同计算机上的文件)时。
在连接上发送任何应用程序数据之前,绑定会在发送方和接收方之间编排 SSPI 握手,指定
Negotiate
安全包(这会选择 NTLM 或 Kerberos 作为实际安全协议,具体取决于各自主机的功能)。作为握手的一部分,安全令牌通过连接进行交换,最终双方的安全提供商将商定会话密钥,用于对后续应用程序消息进行签名和加密。By default the NetTcpBinding uses Transport security, with the default characteristics you list.
Signing and encryption of messages in this context does not mean the same thing as in Message security. Rather it means that all the packets of data sent over the network transport are signed and encrypted. This does not rely on certificates. It is done by security providers installed in the operating system on the sending and receiving machines, invoked via SSPI (Security Support Provider Interface) - the same mechanism involved, for example, when a domain credential is used to access some resource such as a file on a different machine on the network.
Before any application data is sent on a connection, the binding orchestrates an SSPI handshake between the sender and receiver, specifying the
Negotiate
security package (this chooses either NTLM or Kerberos as the actual security protocol, depending on the capabilities of the respective host machines). Security tokens are exchanged over the connection as part of this handshake, at the end of which the two sides' security providers will have agreed session keys for use in the signing and encryption of the ensuing application messages.