Dela via


Authentication with the TCP Channel

This topic is specific to a legacy technology that is retained for backward compatibility with existing applications and is not recommended for new development. Distributed applications should now be developed using the  Windows Communication Foundation (WCF).

The TCP channel directly supports authentication and impersonation. This topic describes how to configure the client and server channels.

The .NET Framework allows servers of remote objects to authenticate and impersonate callers by setting the properties of the associated TcpServerChannel and TcpClientChannel objects.

Server Configuration

To configure a TCP server channel to authenticate remote callers, set the secure property to true on the TCP channel as shown in the following configuration file.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.runtime.remoting>
        <application>
            <channels>
              <channel ref="tcp" secure="true" />
             </channels>
        </application>
    </system.runtime.remoting>
</configuration>

Note

The secure property on the client channel must also be set to true for secure communication to occur. By default secure communication includes authentication and encryption of data sent between the server and client.

The identity of the authenticated client can be accessed by getting the CurrentPrincipal and then accessing its Identity property. The identity of the impersonated client can be accessed by GetCurrent. You can then perform your own authorization if required.

To configure a TCP server channel to authenticate and impersonate remote callers, set the secure property and the impersonate property to true as shown in the following configuration file.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.runtime.remoting>
        <application>
            <channels>
              <channel ref="tcp" secure="true" impersonate="true" />
             </channels>
        </application>
    </system.runtime.remoting>
</configuration>

Note

For impersonation to occur, the tokenImpersonationLevel property on the client channel must be set to impersonation or delegation. Notice that on the server the property is called impersonate but on the client, you set tokenImpersonationLevel to impersonation.

Note

All processes run under a standard user account on Windows Vista. Standard users cannot impersonate an administrator account. If you have a remoting application that must impersonate an administrator account, that application must run under elevated privileges.

The authorizationModule property allows the server to do its own authorization. To use this property you must create a class that implements IAuthorizeRemotingConnection. This interface contains the following methods:

  • IsConnectingEndpointAuthorized, which allows you to authorize a client by IP address.

  • IsConnectingIdentityAuthorized, which allows you to authorize a client by identity.

In the server's configuration file you set the authorizationModule property to the class that implements IAuthorizeRemotingConnection in a string of the form "namespace.class, assembly" as shown in the following configuration file.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.runtime.remoting>
    <application name="AuthorizationApp">
      <service>
        <wellknown mode="SingleCall"
                   type="Server.SampleService, Server"
                   objectUri="Server.rem"/>
      </service>

      <channels>
        <channel ref="tcp" port="8001" secure="true" impersonate="true" authorizationModule="Server.AuthorizationModule,Server"/>
      </channels>
    </application>
  </system.runtime.remoting>
</configuration>

Client Configuration

To configure a TCP client channel to authenticate a caller, set the secure property to true on the TCP channel as shown in the following configuration file.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.runtime.remoting>
        <application>
            <channels>
              <channel ref="tcp" secure="true" />
             </channels>
        </application>
    </system.runtime.remoting>
</configuration>

Note

The secure property on the server channel must also be set to true for secure communication to occur. By default, secure communication includes authentication and encryption of data sent between the server and client.

To configure a TCP client channel to use impersonation set the secure property to true and the tokenImpersonationLevel property to impersonation as shown in the following configuration file.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.runtime.remoting>
        <application>
            <channels>
              <channel ref="tcp" secure="true" tokenImpersonationLevel="impersonation"/>
             </channels>
        </application>
    </system.runtime.remoting>
</configuration>

Note

For impersonation to occur, the impersonate property on the server channel must be set to true. Notice that on the server the property is called impersonate but on the client, tokenImpersonationLevel is set to impersonation.

Note

All processes run under a standard user account on Windows Vista. Standard users cannot impersonate an administrator account. If you have a remoting application that must impersonate an administrator account, that application must run under elevated privileges.

The tokenImpersonationLevel can be set to one of the values in the following table.

tokenImpersonationLevel setting Description

Identification

The server can obtain information about the client, such as security identifiers and privileges, but it cannot impersonate the client.

Impersonation

The server can impersonate the client's security context on its local system. The server cannot impersonate the client on remote systems.

Delegation

The server can impersonate the client on remote systems.

By default, a TCP client channel authenticates itself with the user identity under which the client process is running. You can specify an alternative identity by setting the domain, username, and password properties to specify an alternative identity as shown in the following code sample.

RemotingConfiguration.Configure("Client.exe.config", true);
ISharedInterface remoteObject = (ISharedInterface)Activator.GetObject(
                typeof(ISharedInterface),
                "tcp://localhost:8001/server.rem");

// Set domain, username, and password
IDictionary props = ChannelServices.GetChannelSinkProperties(remoteObject);
props["domain"] = "SomeDomain"; // only required if the user is a member of a domain
props["username"] = "SomeRemotingUser";
props["password"] = "Password123";

// Call method on remote object
remoteObject.HelloWorld("Hi Server");

You can also specify the domain, username, and password properties in a configuration file.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.runtime.remoting>
        <application>
            <channels>
              <channel ref="tcp" 
                       secure="true" 
                       tokenImpersonationLevel="impersonation"
                       username="SomeRemotingUser"
                       password="Password123"
                       />
             </channels>
        </application>
    </system.runtime.remoting>
</configuration>

Note

Hard coding usernames and passwords in code or configuration is not recommended. It is done here only for illustration purposes. The best way to get credentials is to prompt the user.

By default the TCP channel uses NTLM to authenticate callers. To force the channel to use Kerberos, set the servicePrincipalName property to the account the service is running under as shown in the following configuration file.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.runtime.remoting>
        <application>
            <channels>
              <channel ref="tcp" secure="true" tokenImpersonationLevel="impersonation"
                       servicePrincipalName="MyDomain\MyUserAccount"/>
          </channels>
        </application>
    </system.runtime.remoting>
</configuration>

Note

Kerberos requires access to an Active Directory server. If the machines running your code are not members of an Active Directory domain, use NTLM (the default) instead.

See Also

Concepts

Encryption and Message Integrity
Authentication with the HTTP Channel
Authentication with the IPC Channel