Partager via

Hébergement d'objets distants dans Internet Information Services (IIS)

  • Article

Lorsque vous utilisez IIS (Internet Information Services) pour héberger votre type distant, vous ne pouvez pas configurer par programme le système d'accès distant de votre type accessible à distance directement dans le processus hôte, car les domaines d'application hôtes sont créés par IIS et ASP.NET. Cependant, vous pouvez utiliser le fichier Global.asax pour effectuer une configuration par programme comparable à celle que vous pouvez accomplir dans d'autres types de domaines d'application. Pour utiliser un fichier de configuration pour configurer l'accès distant lorsque IIS est votre processus hôte, vous devez procéder ainsi :

  • Placez vos informations de configuration dans le fichier Web.config dans le répertoire virtuel IIS que vous avez choisi d'utiliser.
  • Placez votre implémentation de type accessible à distance dans le répertoire \bin (ou utilisez l'outil Global Assembly Cache Tool (Gacutil.exe) pour la placer dans le cache de l'assembly global).

En outre, vous ne pouvez effectuer aucune des opérations suivantes :

  • Spécifier un nom d'application lorsque l'hébergement est effectué dans IIS. Le nom du répertoire virtuel devient votre nom d'application.
  • Utiliser l'élément <debug> dans un fichier Web.config utilisé pour une configuration .NET Remoting.
  • Utiliser un autre canal que HttpChannel.
  • Utiliser le fichier Web.config et l'élément <client> pour configurer automatiquement votre application Web cliente. Si vous souhaitez utiliser IIS en tant que client d'accès distant, vous devez appeler RemotingConfiguration.Configure dans la méthode Application_Start dans le fichier Global.asax.

Le fichier de configuration pour l'accès distant contiendra encore les informations de base relatives à votre type et qui sont nécessaires au système ; cependant certaines déclarations doivent être légèrement modifiées pour prendre en compte l'environnement d'hébergement. Par exemple, vous pouvez personnaliser la configuration d'un HttpChannel particulier mais vous ne devez pas spécifier un port pour le canal ; si ASP.NET vient à créer un domaine d'application pour gérer la charge, la configuration distante entraînera ce nouveau domaine d'application à tenter d'écouter de nouveau sur le même port, ce qui provoque la levée d'une exception. Par exemple, un fichier Web.config simple pour un service Web XML .NET Remoting hébergé dans IIS (Internet Information Services) peut ressembler à l'exemple de code suivant. Gardez à l'esprit qu'il n'est pas nécessaire d'inclure les lignes relatives à la configuration de canal dans ce cas, sauf pour attacher les propriétés de canal (dans ce cas, la propriété priority) à l'instance utilisée.

<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>

Remarque   N'indiquez pas de port pour les canaux répertoriés ici. Si vous souhaitez que votre application écoute sur un port particulier, utilisez le Gestionnaire des services Internet pour spécifier que IIS écoute sur ce port. Le canal que vous configurez sera automatiquement utilisé pour gérer des demandes distantes soumises sur ce port.

Pour héberger correctement des objets activés par le serveur (c'est-à-dire, <wellknown>) à l'intérieur de IIS, il vous faut un URI (Uniform Resource Identifier) d'objet se terminant par .rem ou .soap. (Cette exigence ne s'applique pas aux autres domaines d'application hôte.) Pour utiliser l'outil Soapsuds Tool (Soapsuds.exe) pour générer des métadonnées pour un objet activé par le serveur hébergé dans IIS, l'URL à passer en tant qu'argument à Soapsuds.exe est :

http://<Ordinateur>:<Port>/<RepVirt>/<URIObjet>?wsdl

Pour les objets activés par le client hébergés dans IIS ou dans n'importe quel autre domaine d'application, vous n'avez besoin d'aucun URI d'objet spécifique. L'URL à passer en tant qu'argument à Soapsuds.exe est :

http://<Ordinateur>:<Port>/<RepVirt>/RemoteApplicationMetadata.rem?wsdl

La configuration par programme dans IIS s'effectue à l'aide de la page Global.asax. L'exemple suivant illustre la même configuration que le fichier de configuration précédent, mais il utilise le fichier 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);
}

En d'autres termes, vous pouvez héberger le service dans IIS de la même façon que pour les autres types de domaines d'application hôte. Pour obtenir un exemple complet, consultez Exemple d'accès distant : hébergement dans Internet Information Services (IIS).

Utilisation des certificats SSL avec .NET Remoting

Des certificats identifient un ordinateur particulier, dont le nom réside dans le nom commun du certificat. Cependant, il est facile de changer le nom d'un ordinateur ou d'utiliser « localhost » dans des fichiers de configuration client, ce qui crée une incompatibilité entre le client et le nom commun dans le certificat de serveur. Dans le .NET Framework version 1.0, cette incompatibilité est ignorée et l'appel est effectué sur le serveur.

À partir de la version 1.1 du .NET Framework, cette incompatibilité lève l'exception suivante : « System.Net.WebException : La connexion sous-jacente a été fermée : Impossible d'établir une relation de confiance avec le serveur distant. » Si vous n'êtes pas en mesure de configurer le client d'accès distant pour utiliser le nom commun du certificat, vous pouvez contourner le problème en utilisant les paramètres suivants dans le fichier de configuration de votre application cliente.

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

Pour que votre client ignore l'incompatibilité des noms de certificat par programme, le client doit créer une instance d'une classe qui implémente l'interface ICertificatePolicy et la méthode CheckValidationResult pour retourner la valeur true si la valeur certificateProblem est 0x800c010f. Vous devez ensuite inscrire l'objet avec l'objet System.Net.ServicePointManager en passant l'objet à la propriété ServicePointManager.CertificatePolicy. Le code suivant illustre une implémentation de 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; 
   }
}

Le code suivant montre comment inscrire une instance de la classe précédente avec System.Net ServicePointManager.

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

Authentification dans des applications d'accès distant hébergées dans IIS

Le tableau suivant décrit les paramètres de configuration qui activent certains types de comportement d'authentification dans .NET Remoting lorsque votre service est hébergé dans IIS (Internet Information Services).

Comportement souhaité Paramètres de configuration Commentaires
Le serveur authentifie le client à chaque appel à l'aide des informations d'authentification par défaut du client . Sur le serveur, sélectionnez Authentification intégrée Windows et désactivez Accès anonyme dans IIS.

Sur le client, définissez les Informations d'authentification pour utiliser CredentialCache.DefaultCredentials.

 Il s'agit du comportement par défaut dans la version 1.0 du .NET Framework lorsque useDefaultCredentials a la valeur true.

Ce comportement est pris en charge dans la version 1.1 du .NET Framework si useAuthenticatedConnectionSharing a également la valeur false.
Le serveur authentifie une fois le client à l'aide des informations d'authentification par défaut ; les appels suivants de ce client utilisent la connexion précédemment authentifiée. Sur le serveur, sélectionnez Authentification intégrée Windows et désactivez Accès anonyme dans IIS.

Sur le client, affectez la valeur true à useDefaultCredentials.

 Ce comportement n'est pris en charge que dans les versions 1.1 et suivantes du .NET Framework.
Le serveur authentifie une fois le client à l'aide des informations d'authentification personnalisées ou explicites du client ; les appels suivants de ce client utilisent la connexion précédemment authentifiée. Sur le serveur, sélectionnez Authentification intégrée Windows et désactivez Accès anonyme dans IIS.

Sur le client, affectez une implémentation ICredentials à credentials ou affectez des valeurs explicites à username, password et domain. Dans les deux cas, vous devez également affecter la valeur true à unsafeAuthenticatedConnectionSharing et fournir une valeur connectionGroupName qui n'est mappée que sur un utilisateur authentifié.

 Ce comportement n'est pris en charge que dans les versions 1.1 et suivantes du .NET Framework.

Voir aussi

URL d'activation | Configuration | Schéma des paramètres d'accès distant | Exemple d'accès distant : hébergement dans Internet Information Services (IIS)