Compartir a través de

Alojar objetos remotos en Servicios de Internet Information Server (IIS)

  • Artículo

Cuando utiliza Servicios de Internet Information Server (IIS) para alojar el tipo remoto, no puede configurar mediante programación el sistema de interacción remota para el tipo utilizable de forma remota directamente en el proceso host, ya que los dominios de aplicación host los crean IIS y ASP.NET. Sin embargo, puede utilizar el archivo Global.asax para realizar gran parte de la configuración mediante programación que se puede realizar en otros tipos de dominios de aplicación. Para usar un archivo de configuración con el fin de configurar la interacción remota cuando IIS es el proceso host, siga este procedimiento:

  • Coloque la información de configuración en el archivo Web.config del directorio virtual de IIS que haya elegido.
  • Coloque la implementación del tipo utilizable de forma remota en el directorio \bin (o utilice la herramienta Caché de ensamblados global (Gacutil.exe) para colocarla en la caché de ensamblados global).

Además, no siga ninguno de estos procedimientos:

  • Especificar un nombre de aplicación cuando se aloja en IIS. El nombre del directorio virtual pasa a ser el de la aplicación.
  • Usar el elemento <debug> en un archivo Web.config utilizado para la configuración de .NET remoting.
  • Usar cualquier canal que no sea HttpChannel.
  • Usar el archivo Web.config y el elemento <client> para configurar automáticamente la aplicación Web de cliente. Si desea utilizar IIS como cliente de interacción remota, debe llamar a RemotingConfiguration.Configure en el método Application_Start del archivo Global.asax.

El archivo de configuración de la interacción remota seguirá incluyendo la información básica que el sistema debe tener a su disposición acerca del tipo, pero algunas declaraciones deben cambiar ligeramente para adaptarse al entorno host. Por ejemplo, puede configurar de forma personalizada un determinado HttpChannel, pero no debe especificar un puerto para el canal; si ASP.NET crea otro dominio de aplicación para poder controlar toda la carga, la configuración de la interacción remota hará que el nuevo dominio de aplicación intente escuchar en el mismo puerto otra vez, lo que generará una excepción. Por ejemplo, un archivo Web.config sencillo para un servicio Web XML de .NET remoting alojado en IIS podría tener un código como el del ejemplo siguiente. Recuerde que no es necesario incluir las líneas de configuración de canales en este caso, excepto para asociar las propiedades de los canales (en este caso, la propiedad priority) a la instancia utilizada.

<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   No especifique un puerto para ninguna de los canales de la lista. Si desea que la aplicación escuche en un puerto concreto, especifíquelo mediante el Administrador de servicios Internet para que IIS escuche en ese puerto. El canal que configure se usará automáticamente para controlar las solicitudes remotas presentadas en ese puerto.

Para alojar correctamente objetos activados en el servidor host (es decir, <wellknown>) en el interior de IIS, debe tener un identificador uniforme de recursos (URI) de objeto que termine en .rem o en .soap. (En otros dominios de aplicación host no hay que cumplir este requisito.) Para usar la herramienta Soapsuds (Soapsuds.exe) con el fin de generar metadatos para un objeto activado en el servidor y alojado en IIS, la dirección URL que debe pasar como argumento a Soapsuds.exe es:

http://<Equipo>:<Puerto>/<DirVirt>/<URIObjeto>?wsdl

Para objetos activados en el cliente y alojados en IIS o en cualquier otro dominio de aplicación, no necesita un URI de objeto de ningún tipo. La dirección URL que debe pasar como argumento a Soapsuds.exe es:

http://<Equipo>:<Puerto>/<DirVirt>/RemoteApplicationMetadata.rem?wsdl

La configuración mediante programación en IIS se lleva a cabo mediante la página Global.asax. En el ejemplo siguiente se muestra una configuración igual que la del archivo de configuración anterior pero se usa el archivo 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 otras palabras, puede alojar el servicio en IIS igual que en otros tipos de dominio de aplicación host. Para obtener un ejemplo completo, vea Ejemplo de interacción remota: Alojar en Servicios de Internet Information Server (IIS).

Usar certificados SSL con .NET Remoting

Los certificados identifican un equipo concreto, cuyo nombre reside en el nombre común del certificado. No obstante, es fácil cambiar el nombre de un equipo o utilizar "localhost" en los archivos de configuración del cliente, que crea una inconsistencia entre el cliente y el nombre común que figura en el certificado del servidor. En .NET Framework versión 1.0, se omite esta inconsistencia y se realizará la llamada en el servidor.

Empezando con .NET Framework versión 1.1, esta inconsistencia inicia la siguiente excepción: "System.Net.WebException: Se ha terminado la conexión: no se puede establecer una relación de confianza con el servidor remoto". Si no puede configurar el cliente de interacción remota para utilizar el nombre común del certificado, podrá reemplazar la inconsistencia mediante los siguientes valores que figuran en el archivo de configuración de la aplicación de cliente.

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

Para que el cliente pase por alto la inconsistencia del nombre del certificado mediante programación, debe crear una instancia de una clase que implemente la interfaz ICertificatePolicy e implemente el método CheckValidationResult para que se devuelva true si el valor de certificateProblem es 0x800c010f. A continuación, se ha de registrar el objeto con el objeto System.Net.ServicePointManager pasándolo a la propiedad ServicePointManager.CertificatePolicy. El siguiente código representa una implementación básica.

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

El siguiente código registra una instancia de la clase anterior con System.Net ServicePointManager.

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

Autenticación en aplicaciones de interacción remota alojadas en IIS

En la siguiente tabla se describen los valores de configuración que permiten determinados tipos de comportamiento de autenticación en .NET remoting cuando se aloja el servicio en Servicios de Internet Information Server (IIS).

Comportamiento deseado Valores de configuración Comentarios
El servidor autentica el cliente en cada llamada mediante las credenciales predeterminadas del cliente. En el servidor, seleccione Autenticación integrada de Windows y desactive Acceso anónimo en IIS.

En el cliente, establezca las credenciales para utilizar CredentialCache.DefaultCredentials.

 Éste es el comportamiento predeterminado en la versión 1.0 de .NET Framework cuando useDefaultCredentials es true.

Este comportamiento se admite en la versión 1.1 de .NET Framework si useAuthenticatedConnectionSharing también está establecido en false.
El servidor autentica el cliente una sola vez mediante las credenciales predeterminadas del cliente; las llamadas posteriores de dicho cliente utilizan la conexión anteriormente autenticada. En el servidor, seleccione Autenticación integrada de Windows y desactive Acceso anónimo en IIS.

En el cliente, establezca useDefaultCredentials en true.

 Este comportamiento se admite únicamente en .NET Framework versión 1.1 o posterior.
El servidor autentica el cliente una sola vez mediante las credenciales personalizadas o explícitas del cliente; las llamadas posteriores de dicho cliente utilizan la conexión anteriormente autenticada. En el servidor, seleccione Autenticación integrada de Windows y desactive Acceso anónimo en IIS.

En el cliente, establezca las credenciales en una implementación ICredentials o bien, establezca username, password y domain en valores explícitos. En ambos casos, también debe establecer unsafeAuthenticatedConnectionSharing en true y proporcionar un valor de connectionGroupName asociado a un solo usuario autenticado.

 Este comportamiento se admite únicamente en .NET Framework versión 1.1 o posterior.

Vea también

Direcciones URL de activación | Configuración | Esquema de la configuración de la interacción remota | Ejemplo de interacción remota: Alojar en Servicios de Internet Information Server (IIS)