Aug 26, 2011 at 6:33 PM
Edited Aug 27, 2011 at 7:18 AM
> First off, I currently use the TcpBinaryServerProtocolSetup, which means I suspect I was looking in the right place.
> However, if you mean that I am using the wrong protocol, please give me reason for doing so.
TcpBinaryClientProtocolSetup/TcpBinaryServerProtocolSetup supports only encryption based on NTLM or Kerberos (Windows Domain is required).
You told, that you don´t want to use Windows based security. This is why I think TcpBinaryServerProtocolSetup is the wrong way.
> If I look at the documentation you linked to, the TcpDuplexClientProtocolSetup/TcpDuplexServerProtocolSetup protocol lists as custom encryption.
> Are you saying that I should use that protocol, if I want to use my own X509 certificate? The documentation does not list that the
> TcpDuplexClientProtocolSetup/TcpDuplexServerProtocolSetup protocol includes default encryption - only the TcpBinaryServerProtocolSetup/TcpBinaryClientProtocolSetup indicates that.
The list inside the documentation says "Standard Windows" not default. Zyan has currently
no encryption implementaion hat supports
There is also no support for SSL/TLS, yet. But SSL and certificates are not needed to establish a encrypted connection when using Zyan.
You have the following options:
- Use Windows integrated security via NTLM or Kerberos (seems to be no real option for you)
- Use Zyan built-in custom security (independend implementation, but with no support for certificates)
- Implement your own encryption sink for Zyan (fantasy is your limit here)
- Don´t encrypt anything
> Would that create an encrypted connection, and if so, how does that work?
You have to set the UseWindowsSecurity property to
Then it will encrypt, but not using any X509 certificate. Your current Windows User Security Token will be used to create an encrypted connection.
If your inside an Active Drectory domain, Kerberos protocol will be used. Otherwise the system falls back to NTLM.
This types of encrypted connection are very good for LAN and VPN applications. You have Single Sign On automaticly, but server and clients
needs to be all part of the same (or a trusted) Windows domain.
But if your application communicates straight over the Internet, you propably will not have the clients in your Windows domain.
Then the Windows based encryption will not work, because the shared infrastructure (Domain Controler with centralized User Database) are not present.
Then TcpDuplexServerProtocolSetup is a good alternative. Duplex means that you can use callbacks ands events even if the client is behind a firewall.
But back to the encryption topic. TcpDuplexServerProtocolSetup encypts your connection automaticly, if you want. All you have to do ist set Encryption = true.
// The third parameter activates encryption
// Replace the NullAuthenticationProvider if you need user authentication
var protocol = new TcpDuplexServerProtocolSetup(endpoint.Port, new NullAuthenticationProvider(), true);
If you tell me, what kind of application you´re writing, I´ll help you to find the best configuration. What are your reqirements?
When the predefined ProtocolSetups don´t fit your requirements, you can create your own ProtocolSetups (like Custom Bindings in WCF)