Authentication

If your remote component exposes sensitive data or operations, it must authenticate its callers to support authorization. The .NET Framework remoting infrastructure does not define an authentication model. The host should handle authentication. For example, you can use ASP.NET to benefit from ASP.NET and IIS authentication features.

If you use a custom Windows service host, develop a custom authentication solution.

ASP.NET Hosting

• The following guidelines apply if you use the ASP.NET host with the HttpChannel :

• Turn off anonymous authentication in IIS .

• Configure ASP.NET for Windows authentication .

• Configure client credentials .

• Increase performance with authenticated connection sharing .

• Force clients to authenticate with each call .

• Control the use of authenticated connections .

Turn off Anonymous Authentication in IIS

To ensure that callers are authenticated by IIS, make sure that your application's virtual directory does not support anonymous authentication. On Windows Server 2003, you should also ensure that .NET Passport authentication is disabled.

Since you have disabled IIS anonymous authentication, you can use any of the supported IIS authentication mechanisms to authenticate callers over the HttpChannel , for example Basic, Digest, and Integrated Windows. To avoid credentials being passed over the network and to take advantage of Windows 2000 security account and password policies, use Integrated Windows authentication.

Configure ASP.NET for Windows Authentication

Configure your application for Windows authentication with the following setting in Web.config:

 <authentication mode="Windows" /> 

You cannot use Passport or Forms authentication because these require redirection to a login page.

Note  

When you use Windows authentication, you are recommended to enable File authorization. For more information, see "Authorization" later in this chapter.

Configure Client Credentials

To successfully communicate with a remote component that is configured for Windows authentication, the client must configure the remoting proxy with the credentials to use for authentication. Failure to do so results in an access denied error.

You can configure the use of default credentials to use the client's current thread or process token, or you can set explicit credentials.

Using Default Credentials

To use the client's process token (or thread token if the client thread is currently impersonating), set the useDefaultCredentials property of the client proxy to true . This results in the use of CredentialsCache.DefaultCredentials when the client receives an authentication challenge from the server. You can configure the proxy either by using the configuration file or programmatically in code. To configure the proxy externally, use the following element in the client configuration file:

 <channel ref="http client" useDefaultCredentials="true" /> 

To set default credentials programmatically, use the following code:

 IDictionary channelProperties; channelProperties = ChannelServices.GetChannelSinkProperties(proxy); channelProperties ["credentials"] = CredentialCache.DefaultCredentials; 

If you use default credentials in an ASP.NET client application that is configured for impersonation, the thread level impersonation token is used. This requires Kerberos delegation.

Using Alternate Credentials

To use a specific set of credentials for authentication when you call a remote object, disable the use of default credentials within the configuration file by using the following setting.

 <channel ref="http" useDefaultCredentials="false" /> 

Note  

Programmatic settings always override the settings in the configuration file.

Then, use the following code to configure the proxy to use specific credentials:

 IDictionary channelProperties =                            ChannelServices.GetChannelSinkProperties(proxy); NetworkCredential credentials; credentials = new NetworkCredential("username", "password", "domain"); ObjRef objectReference = RemotingServices.Marshal(proxy); Uri objectUri = new Uri(objectReference.URI); CredentialCache credCache = new CredentialCache(); // Substitute "authenticationType" with "Negotiate", "Basic", "Digest",  // "Kerberos" or "NTLM" credCache.Add(objectUri, "authenticationType", credentials); channelProperties["credentials"] = credCache; channelProperties["preauthenticate"] = true; 

Increase Performance with Authenticated Connection Sharing

When you set useDefaultCredentials="true" , you should also set the useAuthenticatedConnectionSharing property on the client side to true . This enables the server to reuse authenticated connections, rather than authenticating each incoming call.

 <channel ref="http client" useAuthenticatedConnectionSharing="true" > 

This feature only works with the HttpChannel on version 1.1 of the .NET Framework.

Force Clients to Authenticate With Each Call

Set unsafeAuthenticatedConnectionSharing to false so that clients are not able to supply their own credentials and connection group name to the server.

If you set it to true , unauthenticated clients can possibly authenticate to the server using the credentials of a previously authenticated client. This setting is ignored if the useAuthenticatedConnectionSharing property is set to true . This setting has some performance implications since it closes each connection with the server, which means that clients must authenticate with each call. If you use this setting, you should also specify a ConnectionGroupName for each user that uses the connection.

 <channel ref="http client" unsafeAuthenticatedConnectionSharing="false" > 

This feature only works with the HttpChannel on version 1.1 of the .NET Framework.

Control the Use of Authenticated Connections

If you set unsafeAuthenticationConnectionSharing to true , you should provide a name to group together authenticated connections by setting the connectionGroupName property. If you use default credentials, the connectionGroupName is based on the user account used to run the thread.

 <channel ref="http client" connectiongroupname="<name>" /> 

Custom Process Hosting

If you use a Windows service host and the TcpChannel , either use this approach only in a trusted server scenario, or provide a custom authentication scheme. The following guidelines apply if you use a custom host with the TcpChannel :

• Do not pass plaintext credentials over the network .

• Do not trust IPrincipal objects passed from the client .

Do Not Pass Plaintext Credentials over the Network

If your server requires the client's plaintext credentials, encrypt them before you send them over the network. If your server needs to validate the client credentials, use a challenge/response scheme to validate the credentials on the server. This could include sending a hash, keyed hash, a nonce encrypted with the hash, or a using a digital signature.

However, even in these scenarios, you should use an encrypted communication channel to prevent replay attacks.

Do Not Trust IPrincipal Objects Passed From the Client

Use caution if you pass IPrincipal objects from the client to the server. Untrusted code can create an IPrincipal object, initialize it with roles, and then send it to the server. If the server accepts the IPrincipal without validating it, the client can elevate the privileges of the caller on the server. For example, a malicious caller could create an IPrincipal object that contains common, highly privileged role names such as Administrators, Managers, ExpenseReportApprovers, and Supervisors. When the object is received on the server and placed in the Thread.CurrentPrincipal property, code that calls IsInRole on this object can be deceived into executing privileged code.