Hosting di oggetti remoti in Internet Information Services (IIS)

  • Articolo

Quando si utilizza IIS per contenere il tipo remoto, non è possibile configurare a livello di codice il sistema remoto per il tipo remotizzabile direttamente nel processo host in quanto i domini applicazione host sono creati da IIS e ASP.NET. È tuttavia possibile utilizzare il file Global.asax per eseguire gran parte della stessa configurazione a livello di codice che è possibile eseguire in altri tipi di domini applicazione. Per configurare la comunicazione remota mediante un file di configurazione quando IIS è il processo host, è necessario effettuare le operazioni descritte di seguito.

  • Inserire le informazioni di configurazione nel file Web.config, nella directory virtuale IIS che si è scelto di utilizzare.
  • Collocare l'implementazione del tipo remotizzabile nella directory \bin o utilizzare lo strumento Cache assembly globale(Gacutil.exe), per posizionarla nella cache dell'assembly globale.

Inoltre, non è possibile eseguire le seguenti operazioni:

  • Specificare un nome di applicazione quando l'hosting è in IIS. Il nome della directory virtuale diventa il nome dell'applicazione.
  • Utilizzare l'elemento <debug> in un file Web.config impiegato per la configurazione di .NET Remoting.
  • Utilizzare un canale diverso da HttpChannel.
  • Utilizzare il file Web.config e l'elemento <client> per configurare automaticamente l'applicazione Web client. Se si desidera utilizzare IIS come client remoto, è necessario chiamare RemotingConfiguration.Configure nel metodo Application_Start del file Global.asax.

Nel file di configurazione per la comunicazione remota saranno ancora contenute le informazioni di base sul tipo che il sistema deve conoscere, ma occorrerà modificare leggermente alcune dichiarazioni in modo da adattarle all'ambiente host. È ad esempio possibile personalizzare la configurazione di un determinato HttpChannel, ma non specificare una porta per il canale. Se ASP.NET crea un altro dominio applicazione per gestire il carico, la configurazione di comunicazione remota farà sì che il nuovo dominio applicazione tenti di attendere di nuovo sulla stessa porta, generando un'eccezione. Un semplice file Web.config relativo a un servizio Web XML di .NET Remoting inserito in IIS, ad esempio, sarà simile a quello riportato nell'esempio di codice che segue. In questo caso non è necessario includere le righe di configurazione del canale, fatta eccezione per le proprietà del canale (in questo caso, la proprietà priority) da allegare all'istanza utilizzata.

<configuration>
   <system.runtime.remoting>
      <application>
         <service>
            <wellknown 
               mode="Singleton" 
               type="ServiceClass, ServiceClassAssemblyName"
                objectUri="ServiceClass.rem"
            />
         </service>
         <channels>
            <channel 
               name="MyChannel" 
               priority="100" 
               ref="http"
            />
         </channels>
      </application>
   </system.runtime.remoting>
</configuration>

Nota   Non specificare una porta per tutti i canali elencati. Se si desidera che l'applicazione attenda su una determinata porta, utilizzare Gestione servizi Internet per specificare che IIS dovrà attendere su tale porta. Il canale configurato verrà automaticamente utilizzato per gestire richieste remote inoltrate su tale porta.

Per inserire correttamente in IIS oggetti attivati da server, ossia oggetti <wellknown>, è necessario disporre di un URI (Uniform Resource Identifier) con estensione REM o SOAP per l'oggetto. Questo requisito non si applica ad altri domini applicazione host. Di seguito è riportato l'URL da passare come argomento a Soapsuds.exe per utilizzare lo strumento Soapsuds (Soapsuds.exe) per la generazione di metadati per un oggetto attivato da server e contenuto in IIS.

http://<Computer>:<Porta>/<DiriVirt>/<URIOggetto>?wsdl

Per oggetti attivati da client e contenuti in IIS o in altro dominio applicazione, non occorre un URI di oggetto. L'URL da passare come argomento a Soapsuds.exe è il seguente:

http://<Computer>:<Porta>/<DirVirt>/RemoteApplicationMetadata.rem?wsdl

La configurazione a livello di codice in IIS viene eseguita mediante la pagina Global.asax. Nell'esempio riportato di seguito viene illustrata la medesima configurazione del file di configurazione dell'esempio precedente, ma viene utilizzato il file Global.asax.

Sub Application_Start()
   Dim props = New Hashtable() As IDictionary
   props("name") = "MyChannel" 
   props("priority") = "100" 
   ' Nothing entries specify the default formatters.
   Dim channel As New HttpChannel( _
      props, _
      Nothing, _
      Nothing _
   )
   ChannelServices.RegisterChannel(channel)
   Dim WKSTE As New WellKnownServiceTypeEntry( _
      GetType(ServiceClass), _
      "HttpService", _
      WellKnownObjectMode.SingleCall
   )
   RemotingConfiguration.RegisterWellKnownServiceType(WKSTE)
End Sub
[C#]
void Application_Start(){
   IDictionary props = new Hashtable();
   props["name"] = "MyChannel";
   props["priority"] = "100";
   // Null entries specify the default formatters.
   HttpChannel channel = new HttpChannel(
      props, 
      null, 
      null
   );
   ChannelServices.RegisterChannel(channel);
   WellKnownServiceTypeEntry WKSTE = new WellKnownServiceTypeEntry(
      typeof(ServiceClass),
      "HttpService", 
      WellKnownObjectMode.SingleCall
   );
   RemotingConfiguration.RegisterWellKnownServiceType(WKSTE);
}

Il servizio può essere contenuto in IIS allo stesso modo degli altri tipi di domini applicazione host. Per un esempio completo, vedere Esempio di comunicazione remota: hosting in Internet Information Services (IIS).

Utilizzo di Certificati SSL con .NET Remoting

I certificati consentono di identificare uno specifico computer, il cui nome risiede nel nome comune del certificato. È facile, tuttavia, che il nome di un computer venga modificato o che nei file di configurazione del client sia utilizzato hostlocale e che quindi non vi sia corrispondenza tra il client e il nome comune presente nel certificato del server. In .NET Framework versione 1.0 questa mancata corrispondenza viene ignorata e la chiamata viene richiamata sul server.

A partire dalla versione 1.1 di .NET Framework, in caso di mancata corrispondenza viene generata la seguente eccezione: "System.Net.WebException: Connessione sottostante chiusa: impossibile stabilire una relazione di trust con il server remoto". Se non è possibile configurare il client remoto in modo che utilizzi il nome comune del certificato, si può eseguire l'override della mancata corrispondenza mediante le impostazioni del file di configurazione dell'applicazione client riportate di seguito.

<system.net>
   <settings>
      <servicePointManager
         checkCertificateName="true"
      />
   </settings>
</system.net>

Se si desidera stabilire a livello di codice che il client non tenga conto della mancata corrispondenza del nome comune del certificato, è necessario creare un'istanza di una classe che implementi l'interfaccia ICertificatePolicy e il metodo CheckValidationResult per restituire true se il valore certificateProblem è 0x800c010f. È quindi necessario registrare l'oggetto con l'oggetto System.Net.ServicePointManager passandolo alla proprietà ServicePointManager.CertificatePolicy. Nell'esempio di codice che segue viene illustrata un'implementazione di base.

Public Class MyPolicy Implements ICertificatePolicy 
   Public Function CheckValidationResult(ServicePoint srvPoint, X509Certificate certificate, WebRequest request, Integer certificateProblem) As Boolean
      ' Check for policy common name mismatch. 
       If certificationProblem = 0 Or certificateProblem = &H800c010f Then
         Return True
      Else
         Return False
   End Function
End Class
[C#]
public class MyPolicy : ICertificatePolicy {
   public bool CheckValidationResult(ServicePoint srvPoint, X509Certificate certificate, WebRequest request, int certificateProblem) {
      // Check for policy common name mismatch. 
      if (certificateProblem == 0 || certificateProblem == 0x800c010f)
         return true;
      else
         return false; 
   }
}

Nell'esempio di codice che segue viene registrata un'istanza della classe precedente con System.Net ServicePointManager.

System.Net.ServicePointManager.CertificatePolicy = New MyPolicy()
[C#]
System.Net.ServicePointManager.CertificatePolicy = new MyPolicy();

Autenticazione in applicazioni remote contenute in IIS

Nella tabella riportata di seguito vengono descritte le impostazioni di configurazione che consentono di attivare determinati tipi di comportamento di autenticazione in .NET Remoting quando un servizio è contenuto in Internet Information Services (IIS).

Comportamento desiderato Impostazioni di configurazione Commenti
Il server autentica il client a ogni chiamata utilizzando le credenziali predefinite del client. Sul server selezionare Autenticazione Windows integrata e deselezionare Accesso anonimo in IIS.

Sul client impostare l'utilizzo di CredentialCache.DefaultCredentials per le credenziali.

 Si tratta del comportamento predefinito nella versione 1.0 di .NET Framework quando useDefaultCredentials è impostato su true.

Il comportamento in questione è supportato nella versione 1.1 di .NET Framework se anche useAuthenticatedConnectionSharing è impostato su false.
Il server autentica il client una sola volta utilizzando le credenziali predefinite del client; nelle chiamate successive provenienti dallo stesso client verrà utilizzata la connessione precedentemente autenticata. Sul server selezionare Autenticazione Windows integrata e deselezionare Accesso anonimo in IIS.

Sul client impostare useDefaultCredentials su true.

 Si tratta di un comportamento supportato solo in .NET Framework 1.1 e versioni successive.
Il server autentica il client una sola volta utilizzandone le credenziali esplicite o personalizzate; nelle chiamate successive provenienti dallo stesso client verrà utilizzata la connessione precedentemente autenticata. Sul server selezionare Autenticazione Windows integrata e deselezionare Accesso anonimo in IIS.

Sul client, impostare le credenziali su un'implementazione di ICredentials oppure impostare il nome utente, la password e il dominio su valori espliciti. In entrambi i casi, è necessario impostare anche unsafeAuthenticatedConnectionSharing su true e fornire un valore connectionGroupName con mapping a un solo utente autenticato.

 Si tratta di un comportamento supportato solo in .NET Framework 1.1 e versioni successive.

Vedere anche

URL di attivazione | Configurazione | Schema delle impostazioni remote | Esempio di comunicazione remota: hosting in Internet Information Services (IIS)