In researching .NET Remoting I found a lot of contradictory information on the purpose of the new ensureSecurity flag.
The MSDN Entry for RemotingConfiguration.Configure (the method I need to use in my code) seems to indicate that it is necessary to set it to true to enable security.
ensureSecurity
true to enable security; otherwise, false.
However the entry for ChannelServices.RegisterChannel indicates that it behaves the way you’d expect something named “ensureSecurity” to behave, it makes sure the channel is encrypted, but setting it to false still allows the channel to be encrypted.
ensureSecurity
true ensures that security is enabled; otherwise false. Setting the value to false will not nullify the security setting done on the TCP or IPC channel. For details, see Remarks.
Still confused, I checked the forums. A typical exchange went like this one between MSDN poster JockularJoe and Microsoft SDE Sowmy Srinivasan:
JocularJoe
The old .NET 1.1 Configure method is marked as obsolete, and recommends using a new override with a parameter ensureSecurity.
The MSDN documentation on the ensureSecurity parameter is a bit laconic: "true to enable security; otherwise, false."
I want to maintain backwards compatibility, i.e. don't want to require security. But I may want to use the new security features at some time in the future. What should I set this parameter to? I'm a bit confused that the decision whether to use the new security features is hardwired into the code via this parameter rather than being defined in the configuration file.
Sowmy Srinivasan
ensureSecurity must enable security if set to true. When set to false it should behave the 1.1 way
I hope this helps
Other posts contained a variety of opinions. So I decided to figure this out empirically. I wrote a windows service that exposed a class as a Wellknown service in single call mode, installed it on my server, wrote a quick client to connect to it and fired up Ethereal to watch the traffic between the two. To save you some time I’ll post my conclusion first:
The ensureSecurity flag is equivalent to permanently setting “secure=true”. SSPI encrypted communications is still possible with ensureSecurity set to false. When true, remoting only ignores the “secure” attribute of the channel element in the config file. It still uses the other attributes like impersonate on the server and tokenImpersonationLevel, domain, username and password on the client.
Before I get into the results, let me define a few terms for you:
ensureSecurity: A Boolean flag on the RemotingConfiguration.Configure method. Setting this flag requires all remoting connections to use security, regardless of the value of secure attribute in the app.config file.
secure: A Boolean attribute in the /configuration/system.runtime.remoting/application/channels/channel element of the app.config file for both the client and server. When ensureSecurity is true, this flag is ignored, otherwise, when security is true, encryption is enforced and impersonation is allowed, otherwise plaintext anonymous communication is used. Note that even when impersonation is turned off on the server, the user’s identity still flows to the server, it just isn’t impersonated. You can still authenticate the user and check their role membership.
impersonate: A Boolean attribute in the /configuration/system.runtime.remoting/application/channels/channel element of the app.config file for the server. When true, the process automatically impersonates the calling user. When security=false, setting this to true will cause an exception.
tokenImpersonationLevel: An enumerated attribute in the /configuration/system.runtime.remoting/application/channels/channel element of the app.config file for the client. This setting controls the level of impersonation the server is allowed to perform with your identity. Valid values are Identification, Impersonation and Delegation. When security=false, setting this to true will cause an exception. When connecting to a server set to impersonate, valid values are Impersonation and Delegation.
protectionLevel: An enumerated attribute in the /configuration/system.runtime.remoting/application/channels/channel element of the app.config file for the client. This setting controls the type of encryption to be used. All of the documentation I’ve read recommends setting it to EncryptAndSign I did not test to see if this attribute is used when ensureSecurity is true, mainly because I don’t understand the inner workings of NTLM/Kerberos security well enough to know what I’m looking at in Ethereal.
domain/username/password: Self explanatory. These attributes can be set on the channel element of the client to override the default identity.
Now, for the Ethereal results:
Test 1 (baseline plaintext configuration)
Server ensureEncryption = false secure = false Client ensureEncryption = false secure = false
Client to Server Packet 1 (plaintext URL)
Client to Server Packet 2 (plaintext Wellknown Service Object Info)
Server to Client Packet 1 (plaintext unknown)
Server to Client Packet 2 (plaintext response)
Result: Success with plaintext traffic, WindowsIdentity=Service Account
Test 2 (incompatible client/server security configuration)
Server ensureEncryption =false secure=true impersonate=false Client ensureEncryption =false secure=false
Client to Server Packet 1 (plaintext URL)
Client to Server Packet 2 (plaintext Wellknown Service Object Info)
Result: Failure, No response from server (other than ACK)
Test 3 (encryption turned on in config file only, with no impersonation)
Server ensureEncryption = false secure = true impersonate = false Client ensureEncryption = false secure = true tokenImpersonationLevel = "Impersonation" protectionLevel = "EncryptAndSign"
Client to Server Packet 1 (jibberjabber)
Client to Server Packet 2 (NTLMSSP)
Server to Client 1 (jibberjabber)
Server to Client 2 (NTLMSSP)
Client to Server 3 (jibberjabber)
Client to Server 4 (NTLMSSP response with client identity data)
Server to Client 3 & 4 (jibberjabber)
Client to Server 5 & 6 (jibberjabber)
Server to Client 5 & 6 (jibberjabber)
Result: Success with encrypted traffic, users identity is sent across the wire and is available through the Thread’s CurrentPrincipal, but it is not automatically impersonated. WindowsIdentity=Service Account.
Test 4 (encryption turned on using ensureEncryption flag only, with no impersonation)
Server ensureEncryption = true secure = false Client ensureEncryption = true secure = false
Result: Same as Test 3
Test 5 (encryption turned on both with flag and config file, with impersonation)
Server ensure=true secure=true impersonate=true Client ensure=true secure=true tokenImpersonationLevel="Impersonation"
Result: Same as Tests 3 and 4 except that the server impersonated the client’s identity.
Test 6 (Test 5 but with client’s identity specified using domain/username/password attributes)
Server ensure=true secure=true impersonate=true Client ensure=true secure=true tokenImpersonationLevel="Impersonation" domain=”domainname” username=”username” password=”password”
Result: Same as Tests 3 through 5, except that the client’s identity was as specified.
So there you go. I hope this gets a high enough page rank that it can reduce the confusion out there about secure remoting in .NET 2.0 because it's a really useful feature.