¿Le resultó útil esta página?
Sus comentarios sobre este contenido son muy importantes. Háganos saber su opinión.
¿Tiene comentarios adicionales?
Caracteres restantes: 1500
Exportar (0) Imprimir
Expandir todo

Capítulo 11 – Seguridad de .NET Remoting

Publicado: 26 de junio de 2006

J.D. Meier, Alex Mackman, Michael Dunner, and Srinath Vasireddy
Microsoft Corporation
Octubre de 2002

Consulte la Página de entrada como punto de partida y para obtener una descripción completa del documento Crear aplicaciones ASP.NET seguras.

Resumen: Este capítulo explica cómo implementar soluciones seguras de .NET Remoting.

.NET Framework proporciona una infraestructura de remoting que permite a los clientes comunicarse con objetos alojados en procesos y dominios de aplicaciones remotos, o en equipos remotos. En este capítulo se explica cómo implementar soluciones seguras de .NET Remoting.

En esta página

Arquitectura de .NET Remoting Arquitectura de .NET Remoting
Guardianes de .NET Remoting Guardianes de .NET Remoting
Autenticación Autenticación
Autorización Autorización
Estrategias de autenticación y autorización Estrategias de autenticación y autorización
Obtener acceso a recursos del sistema Obtener acceso a recursos del sistema
Obtener acceso a recursos de red Obtener acceso a recursos de red
Transmitir credenciales de autenticación a objetos remotos Transmitir credenciales de autenticación a objetos remotos
Transmitir el llamador original Transmitir el llamador original
Subsistema de confianza Subsistema de confianza
Comunicación segura Comunicación segura
Elegir un proceso de host Elegir un proceso de host
Remoting y servicios Web Remoting y servicios Web
Conclusión Conclusión

Arquitectura de .NET Remoting

La ilustración 11.1 muestra la arquitectura básica de .NET Remoting cuando se aloja en ASP.NET un objeto remoto. Si la seguridad es el factor principal, se recomienda utilizar ASP.NET como host junto con el canal HTTP para la comunicación, porque permite al objeto remoto utilizar los servicios de seguridad subyacentes que proporcionan ASP.NET e IIS.
Para obtener más información acerca de los distintos tipos de host y de canales posibles, junto con información comparativa, consulte "Elegir un proceso de host" más adelante en este capítulo.

imagen

Ilustración 11.1

La arquitectura de .NET Remoting

El cliente se comunica con un objeto proxy en proceso. Las credenciales de autenticación (por ejemplo, nombres de usuario, contraseñas, certificados, etc.) pueden establecerse mediante el proxy del objeto remoto. La llamada de método pasa por una cadena de receptores (puede implementar sus propios receptores personalizados, como por ejemplo, para realizar el cifrado de los datos) hasta un receptor de transporte que se encarga de enviar los datos por la red. En el servidor, la llamada pasa por la misma canalización y, a continuación, se distribuye al objeto.

Nota

En este capítulo, el término proxy se refiere al objeto proxy en proceso, de cliente, mediante el cual los clientes se comunican con el objeto remoto. No lo confunda con el término servidor Proxy

Receptores de remoting

.NET Remoting utiliza receptores de canales de transporte, receptores de canales personalizados y receptores de canales de formateador cuando un cliente invoca una llamada de método en un objeto remoto.

Receptores de canales de transporte

  • HttpChannel. Este canal se ha diseñado para utilizarse cuando se aloja un objeto remoto en ASP.NET. Usa el protocolo HTTP para enviar mensajes entre el cliente y el servidor.

  • TcpChannel. Este canal se ha diseñado para utilizarse cuando se aloja un objeto remoto en un servicio del sistema operativo Microsoft® Windows® o en otro ejecutable. Usa sockets TCP para enviar mensajes entre el cliente y el servidor.

  • Canales personalizados. Los canales de transporte personalizados pueden utilizar cualquier protocolo de transporte subyacente para enviar mensajes entre el cliente y el servidor. Por ejemplo, pueden utilizar canalizaciones con nombre o buzones interproceso.

Comparación de receptores de canales de transporte

La siguiente tabla contiene una comparación de los dos receptores de canales de transporte principales.

Tabla 11.1: Comparación de TcpChannel y HttpChannel

Característica

Canal TCP

Canal HTTP

Comentarios

Autenticación

No

El canal HTTP utiliza las características de autenticación proporcionadas por IIS y ASP.NET, aunque no se admite la autenticación de Passport ni mediante Formularios.

Autorización

No

El canal HTTP admite las características de autorización proporcionadas por IIS y ASP.NET, entre las que figuran los permisos de NTFS, la autorización de direcciones URL y la autorización de archivos.

Comunicación segura

Utilice IPSec con el canal TCP. Utilice SSL o IPSec con el canal HTTP.

Receptores personalizados

Los receptores de canales personalizados pueden utilizarse en distintas ubicaciones de la canalización de receptores de canales para modificar los mensajes enviados entre el cliente y el servidor. Un receptor de canales que proporciona cifrado y descifrado constituye un ejemplo de receptor de canales personalizado.

Receptores del formateador

Los receptores del formateador reciben llamadas de método y las serializan en un flujo que se puede enviar por la red. .NET proporciona dos receptores de formateador:

  • Formateador binario. Utiliza la clase BinaryFormatter para empaquetar llamadas de método en forma de flujo binario serializado, que se expone posteriormente (mediante HTTP POST) para enviar los datos al servidor. El formateador binario establece el tipo de contenido de la petición HTTP en "application/octet-stream".

    El formateador binario ofrece un rendimiento muy alto en comparación con el formateador SOAP.

  • Formateador SOAP. Utiliza la clase SoapFormatter para empaquetar llamadas de método en forma de mensaje SOAP. El tipo de contenido de la petición HTTP se establece en "text/xml" y se expone en el servidor con HTTP POST.

Anatomía de una petición con ASP.NET como host

El direccionamiento a los extremos de objetos remotos se realiza mediante direcciones URL que terminan con la extensión de nombre de archivo .rem o .soap, como por ejemplo, http://servidor/vDir/objetoRemoto.soap. Cuando IIS recibe una petición de un objeto remoto (con la extensión .rem o .soap), se asigna (en IIS) a la extensión ISAPI de ASP.NET (Aspnet_isapi.dll). La extensión ISAPI reenvía la petición a un dominio de aplicación del proceso de trabajo de ASP.NET (Aspnet_wp.exe). La ilustración 11.2 muestra la secuencia de eventos.

imagen

Ilustración 11.2

Procesamiento del servidor

La ilustración 11.2 muestra la siguiente secuencia de eventos:

  1. Se recibe por HTTP una petición .soap o .rem y se asigna a un directorio virtual específico del servidor Web.

  2. IIS comprueba la asignación de .soap/.rem y asigna la extensión de archivo a la extensión ISAPI de ASP.NET, Aspnet_isapi.dll.

  3. La extensión ISAPI transfiere la petición a un dominio de aplicación del proceso de trabajo de ASP.NET (Aspnet_wp.exe). Si se trata de la primera petición dirigida a esta aplicación, se crea un nuevo dominio de aplicación.

  4. Se invoca el controlador HttpRemotingHandlerFactory y la infraestructura de remoting lee la sección <system.runtime.remoting> del archivo Web.config que controla la configuración de objetos del servidor (por ejemplo, parámetros de llamada única o singleton) y los parámetros de autorización (del elemento <authorization>).

  5. La infraestructura de remoting localiza el ensamblado que contiene el objeto remoto y crea una instancia del mismo.

  6. La infraestructura de remoting lee los encabezados HTTP y el flujo de datos y, a continuación, invoca el método del objeto remoto.

Nota

Durante este proceso, ASP.NET llama a la secuencia normal de controladores de eventos. Opcionalmente, puede implementar uno o varios de ellos en Global.asax, como por ejemplo, BeginRequest, AuthenticationRequest, AuthorizeRequest, etc. Cuando la petición alcanza el método del objeto remoto, el objeto IPrincipal que representa al usuario autenticado se almacena en HttpContext.User (y en Thread.CurrentPrincipal) y está disponible para la autorización. Ésta puede realizarse, por ejemplo, mediante peticiones de permisos de entidades principales y comprobaciones de funciones mediante programación.

ASP.NET y el canal http

Remoting no dispone de su propio modelo de seguridad. La autenticación y la autorización entre el cliente (proxy) y el servidor (objeto remoto) las realizan el canal y el proceso de host. Puede utilizar la siguiente combinación de hosts y canales:

  • Un archivo ejecutable personalizado y el canal TCP. Esta combinación no proporciona ninguna característica de seguridad integrada.

  • ASP.NET y el canal HTTP. Esta combinación proporciona autenticación y autorización a través de las características de seguridad subyacentes de ASP.NET e IIS.

Los objetos alojados en ASP.NET se benefician de las características de seguridad subyacentes de ASP.NET e IIS. Entre ellas, figuran:

  • Características de autenticación. La autenticación de Windows se configura en el archivo Web.config:

<authentication mode="Windows"/>

La configuración de IIS controla el tipo de autenticación HTTP utilizada.

Se utilizan encabezados HTTP comunes para autenticar peticiones. Puede proporcionar credenciales para el cliente mediante la configuración del proxy del objeto remoto o utilizar credenciales predeterminadas.

No puede utilizar la autenticación de Passport o mediante Formularios porque el canal no proporciona al cliente una forma de acceso a cookies, requisito de estos dos mecanismos de autenticación. Además, estos mecanismos requieren una redirección a una página de inicio de sesión en la que es necesaria la interacción del cliente. Los objetos remotos del servidor se han diseñado para utilizarse de forma no interactiva.

  • Características de autorización. Los clientes se autorizan mediante técnicas de autorización estándar de ASP.NET.

Entre las opciones de autorización configurables, figuran:

  • Autorización de direcciones URL.

  • Autorización de archivos (requiere una configuración específica, tal y como se describe en "Utilizar la autorización de archivos" más adelante en este capítulo).

Entre las opciones de autorización programables, figuran:

  • Peticiones de permisos de principales (declarativas e imperativas).

  • Comprobaciones de funciones explícitas con IPrincipal.IsInRole.

  • Características de comunicación segura. SSL (o IPSec) debe utilizarse para proteger el transporte de datos entre el cliente y el servidor.

Más información

Guardianes de .NET Remoting

Los puntos de autorización (o guardianes) que se encuentran disponibles para un objeto remoto alojado en ASP.NET son:

  • ASP.NET

    • UrlAuthorizationModule. Puede configurar elementos <authorization> en el archivo Web.config de la aplicación para controlar los usuarios y los grupos de usuarios que podrían tener acceso a la aplicación. La autorización se basa en el objeto IPrincipal almacenado en HttpContext.User.

    • FileAuthorizationModule. FileAuthorizationModule está disponible para componentes remotos, aunque requiere una configuración específica, tal y como se describe en "Utilizar la autorización de archivos" más adelante en este capítulo.

    Nota

    La autorización de archivos no requiere el uso de la suplantación.

La clase FileAuthorizationModule sólo realiza controles de acceso del archivo o URI solicitado (como .rem y .soap) y no de los archivos a los que se obtiene acceso mediante código en el objeto remoto.

  • Peticiones de permisos de principales y comprobaciones de funciones explícitas. Además de los guardianes configurables IIS y ASP.NET, también puede utilizar peticiones de permisos de principales (de forma declarativa o imperativa) como mecanismo adicional de control de acceso específico. Las comprobaciones de permisos de principales le permiten controlar el acceso a clases, métodos o bloques individuales de código en función de la identidad y la pertenencia a grupos de determinados usuarios, tal y como lo define el objeto IPrincipal que está adjunto al subproceso actual.

Nota

Las comprobaciones de permisos de principales utilizadas para solicitar la pertenencia a funciones son distintas de las llamadas realizadas a IPrincipal.IsInRole para probar la pertenencia a funciones. Las primeras generan una excepción si el llamador no es miembro de la función especificada, mientras que las segundas devuelven solamente un valor booleano para confirmar la pertenencia a funciones.

Con la autenticación de Windows, ASP.NET adjunta automáticamente un objeto WindowsPrincipal que representa al usuario autenticado en la petición Web actual (mediante HttpContext.User).

Autenticación

Al utilizar remoting de forma conjunta con un cliente de una aplicación Web ASP.NET, la autenticación se realiza en la aplicación Web y en el host del objeto remoto. Las opciones de autenticación disponibles para el host del objeto remoto dependen del tipo de host.

Utilizar ASP.NET como host

Cuando los objetos se alojan en ASP.NET, el canal HTTP sirve para transmitir llamadas de método entre el proxy del cliente y el servidor. El canal HTTP utiliza el protocolo HTTP para autenticar el proxy del objeto remoto en el servidor.

La siguiente lista muestra las distintas opciones de autenticación que se encuentran disponibles cuando se utiliza ASP.NET como host:

  • Opciones de autenticación de IIS. Anónima, básica, implícita, integrada de Windows y certificados.

  • Opciones de autenticación de ASP.NET. Autenticación de Windows o ninguna autenticación (para implementaciones de autenticación personalizadas).

Nota

.NET Remoting no puede utilizar directamente la autenticación mediante Formularios ni la de Passport. Las llamadas a objetos remotos se han diseñado para utilizarse de forma no interactiva. Si el cliente del objeto remoto es una aplicación Web .NET, la aplicación Web puede utilizar la autenticación mediante Formularios y la de Passport y transmitir credenciales de forma explícita al objeto remoto. Este tipo de escenario se explica con mayor detalle en la sección "Transmitir el llamador original" más adelante en este capítulo.

Utilizar un servicio de Windows como host

Cuando los objetos se alojan en un servicio de Windows, el canal TCP sirve para transmitir llamadas de método entre el cliente y el servidor. Para ello, se utilizan comunicaciones de bajo nivel basadas en sockets. Puesto que no se proporciona ninguna autenticación con los sockets, el servidor no puede autenticar el cliente de ninguna forma.

En este escenario, el objeto remoto debe utilizar la autenticación personalizada.

Autenticación personalizada

Para la autenticación personalizada simple, el objeto remoto puede exponer un método Login que acepta un nombre de usuario y una contraseña. Las credenciales pueden validarse con un almacén, una lista de funciones recuperadas y un testigo devuelto al cliente para su uso en peticiones posteriores. Cuando se recupera el testigo en el servidor, se utiliza para crear un objeto IPrincipal (con funciones) que se almacena en Thread.CurrentPrincipal, donde se utiliza para llevar a cabo la autorización.

Entre otros ejemplos de autenticación personalizada, figuran la creación de un receptor de canales de transporte personalizado que utiliza un canal de comunicación entre procesos para la autenticación, como las canalizaciones con nombre, o la creación de un receptor de canales que lleva a cabo la autenticación mediante SSPI (Interfaz de proveedor de servicios de seguridad de Windows, Windows Security Service Provider Interface).

Más información

  • Para obtener más información acerca de cómo alojar un objeto en un servicio de Windows, consulte "Cómo alojar un objeto remoto en un servicio de Windows" en la sección Referencia de esta guía.

  • Para obtener más información acerca de los receptores y las cadenas de receptores, realice búsquedas en la sección de .NET Framework sobre "Sinks and Sink Chains" en MSDN Library (en inglés).

  • Para obtener más información acerca de cómo crear una solución de autenticación personalizada que utilice SSPI, consulte el artículo de MSDN ".NET Remoting Security Solution, Part 1: Microsoft.Samples.Security.SSPI Assembly" (en inglés) en http://msdn.microsoft.com/library/en-us/dndotnet/html/remsspi.asp.

Nota

La implementación de este artículo es un ejemplo y no un producto probado y admitido por Microsoft.

Autorización

Cuando se alojan los objetos en ASP.NET y el canal HTTP se utiliza para la comunicación, el cliente puede autenticarse y la autorización puede controlarse con los siguientes mecanismos:

  • Autorización de direcciones URL

  • Autorización de archivos

  • Peticiones de permisos de principales (declarativas e imperativas)

  • Comprobaciones de IPrincipal.IsInRole en el código

Cuando se alojan los objetos en un servicio de Windows, el canal TCP no proporciona autenticación. Por consiguiente, debe llevar a cabo la autenticación personalizada y después la autorización mediante la creación de un objeto IPrincipal y su almacenamiento en Thread.CurrentPrincipal.

A continuación, puede anotar los métodos del objeto remoto con comprobaciones de peticiones de permisos de principales, tal y como se muestra a continuación:

[PrincipalPermission(SecurityAction.Demand, 
   Role="Manager")]
   void SomeMethod()
   {
   }

En el código de método del objeto, también puede utilizar peticiones de permisos de principales imperativas y comprobaciones de funciones explícitas mediante IPrincipal.IsInRole.

Utilizar la autorización de archivos

Puede que desee utilizar el control de acceso integrado de Windows para proteger el objeto remoto como recurso de Windows que se puede proteger. Sin la autorización de archivos (con ACL de Windows), sólo dispone de la autorización de direcciones URL.

Si desea utilizar FileAuthorizationModule para autorizar el acceso a extremos de objetos remotos (identificados con direcciones URL .rem o .soap), deberá crear un archivo físico con la extensión .rem o .soap en el directorio virtual de la aplicación.

Nota

Las extensiones .rem y .soap las utiliza IIS para asignar peticiones de extremos de objetos a la extensión ISAPI de ASP.NET (aspnet_isapi.dll). No suelen existir como archivos físicos.

Para configurar la autorización de archivos para .NET Remoting:

  1. Cree un archivo con el mismo nombre que el objectUri (por ejemplo, RemoteMath.rem) en la raíz del directorio virtual de la aplicación.

  2. Agregue la siguiente línea al principio del archivo y guárdelo.

    <%@ webservice class="YourNamespace.YourClass" ... %>
    
  3. Agregue una ACL correctamente configurada al archivo mediante el Explorador de Windows.

Nota

Puede obtener el objectUri del archivo web.config que se utiliza para configurar el objeto remoto en el servidor. Busque el elemento <wellknown>, tal y como se muestra en el siguiente ejemplo:

<wellknown mode="SingleCall" objectUri="RemoteMath.rem"    
type="RemotingObjects.RemoteMath, RemotingObjects, Version=1.0.000.000    
Culture=neutral, PublicKeyToken=4b5ae668c251b606"/>

Más información

  • Para obtener más información acerca de estos mecanismos de autorización, consulte el capítulo 8, "Seguridad de ASP.NET".

  • Para obtener más información acerca de las peticiones de permisos de principales, consulte "Peticiones PrincipalPermission" en la sección "Introducción" de esta guía.

Estrategias de autenticación y autorización

En muchas aplicaciones que utilizan .NET Remoting, los objetos remotos sirven para proporcionar funcionalidad empresarial en el nivel medio de la aplicación y las aplicaciones Web ASP.NET llaman a esta funcionalidad. Este escenario se muestra en la ilustración 11.3.

imagen

Ilustración 11.3

Objetos remotos llamados por una aplicación Web ASP.NET

En este escenario, los guardianes IIS y ASP.NET de los que dispone la aplicación Web pueden utilizarse para proteger el acceso al proxy del cliente, mientras que los guardianes IIS y ASP.NET de los que dispone el host ASP.NET en el servidor de aplicaciones remoto pueden utilizarse para proteger el acceso al objeto remoto.

Existen básicamente dos estrategias de autenticación y autorización para objetos remotos a los que tienen acceso aplicaciones Web .NET.

  • Puede autenticar y autorizar llamadores en el servidor Web y después transmitir el contexto de seguridad del llamador al objeto remoto mediante la suplantación. Éste es el modelo de suplantación/delegación.

En este enfoque, se utiliza un mecanismo de autenticación de IIS que le permite delegar el contexto de seguridad del llamador, como la autenticación Kerberos, básica o mediante Formularios (las dos últimas permiten a la aplicación Web obtener acceso a las credenciales del llamador), y transmitir credenciales de forma explícita al objeto remoto mediante el proxy del objeto remoto.
Los guardianes configurables y programables de ASP.NET (como la autorización de direcciones URL, la autorización de archivos, las peticiones de permisos de principales y las funciones de .NET) están disponibles para autorizar llamadores individuales en el objeto remoto.

  • Puede autenticar y autorizar llamadores en el servidor Web y después utilizar una identidad de confianza para comunicarse con el objeto remoto. Éste es el modelo de subsistemas de confianza.

    Este modelo depende de la aplicación Web para realizar la autenticación y la autorización correcta de llamadores antes de invocar el objeto remoto. Se permite continuar con el procesamiento de todas las peticiones recibidas por el objeto remoto provenientes de la identidad de confianza proyectada desde la aplicación Web.

Más información

  • Para obtener más información acerca de los modelos de suplantación/delegación y de subsistemas de confianza, consulte "Modelos de acceso a recursos" en el capítulo 3, "Autenticación y autorización".

  • Para obtener más información acerca del uso del modelo de llamador original con remoting, consulte "Transmitir el llamador principal" más adelante en este capítulo.

  • Para obtener más información acerca del uso del modelo de subsistemas de confianza con remoting, consulte "Subsistema de confianza" más adelante en este capítulo.

Obtener acceso a recursos del sistema

Para obtener información acerca de cómo obtener acceso a recursos del sistema (por ejemplo, al registro de sucesos y al registro) desde un objeto remoto alojado en ASP.NET, consulte "Obtener acceso a recursos de sistema" en el capítulo 8, "Seguridad de ASP.NET". Los enfoques y restricciones descritos en el capítulo 8 se aplican también a los objetos remotos alojados por ASP.NET.

Obtener acceso a recursos de red

Cuando obtiene acceso a recursos de red desde un objeto remoto, deberá considerar la identidad que se utiliza para responder a los desafíos de autenticación de red desde el equipo remoto. Dispone de tres opciones:

  • La identidad del proceso (predeterminada). Si usa ASP.NET como host, la identidad utilizada para ejecutar el proceso de trabajo de ASP.NET y definida por el elemento <processModel> en el archivo Machine.config determina el contexto de seguridad utilizado para el acceso a los recursos.

    Si usa un servicio de Windows como host, la identidad utilizada para ejecutar el proceso del servicio (configurado con el complemento MMC de servicios) determina el contexto de seguridad utilizado para el acceso a los recursos.

  • Una identidad de servicio fija. Por ejemplo, una identidad creada mediante la llamada a LogonUser.

Nota

No confunda esta identidad de servicio con la identidad que se utiliza para ejecutar un servicio de Windows. Las identidades de servicio fijas hacen referencia a una cuenta de usuario de Windows creada específicamente con el fin de obtener acceso a recursos desde una aplicación.

  • La identidad del llamador original. Se utiliza con ASP.NET configurado para la suplantación o con la suplantación programable en un servicio de Windows.

Para obtener información acerca de las ventajas relativas de cada uno de estos enfoques, junto con información de configuración, consulte "Obtener acceso a recursos de red" en el capítulo 8, "Seguridad de ASP.NET".

Transmitir credenciales de autenticación a objetos remotos

Cuando un proceso de cliente llama a un objeto remoto, utiliza un proxy para realizar la llamada. Se trata de un objeto local que expone el mismo conjunto de métodos que el objeto de destino.

Especificar credenciales del cliente

Si el objeto remoto está alojado en ASP.NET y configurado para la autenticación de Windows, deberá especificar las credenciales de autenticación mediante la propiedad credentials del canal. Si no define explícitamente las credenciales, la llamada al objeto remoto se realiza sin utilizar ninguna credencial. Si se requiere la autenticación de Windows, se generará un estado HTTP 401, que es una respuesta de acceso denegado.

Utilizar DefaultCredentials

Si desea utilizar las credenciales del proceso que aloja el proxy del objeto remoto (o el testigo del subproceso actual si el subproceso que llama al proxy usa la suplantación), deberá establecer la propiedad credentials del canal en las DefaultCredentials mantenidas por la caché de credenciales del proceso.

Puede especificar el uso de DefaultCredentials en un archivo de configuración o establecer las credenciales mediante programación.

Configuración explícita

En el archivo de configuración de la aplicación cliente (Web.config, si la aplicación cliente es una aplicación Web ASP.NET), establezca el atributo useDefaultCredentials del elemento <channel> en true para especificar que el proxy debe utilizar DefaultCredentials cuando se comunica con el objeto remoto.

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

Configuración mediante programación

En este tipo de configuración, utilice el siguiente código para establecer el uso de DefaultCredentials mediante programación.

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

Utilizar credenciales específicas

Si desea utilizar un conjunto específico de credenciales para realizar la autenticación al llamar a un objeto remoto, deshabilite el uso de las credenciales predeterminadas en el archivo de configuración mediante la opción siguiente:

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

Nota

La configuración mediante programación reemplaza siempre la configuración del archivo de configuración.

A continuación, utilice el siguiente código para configurar el uso de credenciales específicas por parte del proxy:

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;

Solicitar siempre un tipo de autenticación específico

Siempre debería solicitar un tipo de autenticación específico con el método CredentialCache.Add, tal y como se mostró anteriormente. Evite utilizar directamente la clase NetworkCredential, como se muestra en el siguiente código:

IDictionary providerData = 
ChannelServices.GetChannelSinkProperties(yourProxy);
   providerData["credentials"] = new NetworkCredential(uid, pwd);

Debe evitarse en código de producción, puesto que no podrá controlar el mecanismo de autenticación que utiliza el host del objeto remoto y, por consiguiente, tampoco podrá controlar cómo se utilizan las credenciales.

Por ejemplo, podría estar esperando un desafío de autenticación Kerberos o NTLM por parte del servidor, pero en su lugar podría recibir un desafío de autenticación básica. En este caso, el nombre de usuario y la contraseña proporcionados se envían al servidor como texto no cifrado.

Establecer la propiedad preauthenticate

La propiedad preauthenticate del proxy puede establecerse en true o en false. Utilice true (tal y como se muestra en el código anterior) para proporcionar credenciales de autenticación específicas que hagan que se transmita un encabezado HTTP WWW-Authenticate con la petición inicial. Así se evita que el servidor Web deniegue el acceso a la petición inicial y lleve a cabo la autenticación de la siguiente petición.

Utilizar la propiedad connectiongroupname

Si tiene una aplicación Web ASP.NET que se conecta a un componente remoto (alojado por ASP.NET) y transmite el contexto de seguridad del llamador original (mediante DefaultCredentials y suplantación o mediante el establecimiento de credenciales específicas, tal y como se mostró anteriormente), deberá establecer la propiedad connectiongroupname del canal en la aplicación Web. De este modo, se evita que un cliente nuevo no autenticado reutilice una conexión previa autenticada al componente remoto que está asociado a las credenciales de autenticación de un cliente anterior. La reutilización de conexiones puede producirse como resultado de KeepAlives HTTP y la persistencia de la autenticación que está habilitada en IIS por motivos de rendimiento.

Establezca la propiedad connectiongroupname en un identificador (como el nombre de usuario del llamador) que distinga entre llamadores.

channelProperties["connectiongroupname"] = userName;

Nota

No es necesario que establezca la propiedad connectiongroupname si el contexto de seguridad del llamador original no se transmite por la aplicación Web hasta el componente remoto, sino que se conecta a éste mediante una identidad fija (como la identidad del proceso de ASP.NET de la aplicación Web). En este escenario, el contexto de seguridad de la conexión se mantiene constante de un llamador a otro.

La próxima versión de .NET Framework va a admitir la agrupación de conexiones en función del SID del subproceso que llama al objeto de proxy, lo que ayudará a solucionar el problema anterior, si la aplicación Web suplanta al llamador. Se admitirá la agrupación para clientes de .NET Remoting, pero no para los de servicios Web.

Transmitir el llamador original

Esta sección describe cómo puede transmitir el contexto de seguridad del llamador original por una aplicación Web ASP.NET hasta un componente remoto alojado por ASP.NET en un servidor de aplicaciones remoto. Puede que necesite utilizar este enfoque para admitir la autorización por usuario en el objeto remoto o en subsistemas posteriores de nivel inferior (como bases de datos).

En la ilustración 11.4, el contexto de seguridad del llamador original (Bob) se transmite por el servidor Web cliente que aloja una aplicación Web ASP.NET hasta el objeto remoto alojado por ASP.NET en un servidor de aplicaciones remoto y, finalmente, hasta un servidor de bases de datos que actúa como servidor.

imagen

Ilustración 11.4

Transmitir el contexto de seguridad del llamador original

Para transmitir credenciales a un objeto remoto, el cliente del objeto remoto (la aplicación Web ASP.NET en este escenario) debe configurar el proxy del objeto y establecer explícitamente la propiedad credentials del proxy, tal y como se describe en "Transmitir credenciales de autenticación a objetos remotos" anteriormente en este capítulo.

Nota

Los objetos IPrincipal no se transmiten por los límites de .NET Remoting.

Existen dos formas de transmitir el contexto del llamador:

  • Transmitir credenciales predeterminadas y utilizar la autenticación Kerberos (y la delegación). Este enfoque requiere que realice la suplantación en la aplicación Web ASP.NET y configure el proxy del objeto remoto con DefaultCredentials obtenidas del contexto de seguridad del llamador suplantado

  • Transmitir credenciales explícitas y utilizar la autenticación básica o mediante Formularios. Este enfoque no requiere la suplantación en la aplicación Web ASP.NET. En su lugar, se utiliza programación para configurar el proxy del objeto remoto con credenciales explícitas obtenidas de variables de servidor (con la autenticación básica) o de campos de formularios HTML (con la autenticación mediante Formularios) que están disponibles para la aplicación Web. En la autenticación básica o mediante Formularios, el nombre de usuario y la contraseña se transmiten al servidor como texto no cifrado

Credenciales predeterminadas con delegación Kerberos

Para utilizar la delegación Kerberos, todos los equipos (servidores y clientes) deben ejecutar Windows 2000 o posterior. Además, las cuentas de cliente que se van a delegar deben estar almacenadas en el servicio de directorios de Active Directory™ y no deben estar marcadas como "Importante y no se puede delegar".

Las siguientes tablas contienen los pasos de configuración necesarios en el servidor Web y en el servidor de aplicaciones.

Configurar el servidor Web

Configurar IIS

Paso

Más información

Deshabilitar el acceso anónimo para el directorio raíz virtual de la aplicación Web
Habilitar la autenticación integrada de Windows para la raíz virtual de la aplicación Web

La autenticación Kerberos se negocia suponiendo que los clientes y el servidor ejecutan Windows 2000 o posterior.
Nota: si utiliza Microsoft Internet Explorer 6 en Windows 2000, éste utiliza la autenticación NTLM de forma predeterminada en lugar de la autenticación Kerberos requerida. Para habilitar la delegación Kerberos, consulte el artículo Q299838, "Unable to Negotiate Kerberos Authentication after upgrading to Internet Explorer 6" (en inglés), en Microsoft Knowledge Base.

Configurar ASP.NET

Paso

Más información

Configurar la aplicación Web ASP.NET para que utilice la autenticación de Windows

Edite el archivo Web.config en el directorio virtual de la aplicación Web.

Establezca el elemento <authentication> en:

<authentication mode="Windows" />

Configurar la aplicación Web ASP.NET para la suplantación

Edite el archivo Web.config en el directorio virtual de la aplicación Web.

Establezca el elemento <identity> en:

<identity impersonate="true" />

Configurar Remoting (proxy del cliente)

Paso

Más información

Configurar el proxy del objeto remoto para que utilice credenciales predeterminadas para todas las llamadas al objeto remoto

Agregue la siguiente entrada al archivo Web.config:

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

Las credenciales se obtendrán del testigo de suplantación del subproceso de la aplicación Web.

Configurar el servidor de aplicaciones remoto

Configurar IIS

Paso

Más información

Deshabilitar el acceso anónimo para el directorio raíz virtual de la aplicación Web
Habilitar la autenticación integrada de Windows para la raíz virtual de la aplicación Web

.

Configurar ASP.NET (host del objeto remoto)

Paso

Más información

Configurar ASP.NET para que utilice la autenticación de Windows

Edite el archivo Web.config en el directorio virtual de la aplicación.

Establezca el elemento <authentication> en:

<authentication mode="Windows" />

Configurar ASP.NET para la suplantación

Edite el archivo Web.config en el directorio virtual de la aplicación.

Establezca el elemento <identity> en:

<identity impersonate="true"          />

Nota: este paso sólo es necesario si desea transmitir el contexto de seguridad del llamador original por el objeto remoto hasta el siguiente subsistema de nivel inferior (como una base de datos). Al estar habilitada la suplantación, el acceso a recursos (locales y remotos) utiliza el contexto de seguridad del llamador original suplantado.

Si se requiere solamente permitir las comprobaciones de autorización por usuario en el objeto remoto, no es necesario utilizar la suplantación.

Más información

Para obtener más información acerca de la delegación Kerberos, consulte "Cómo: Implementar la delegación Kerberos en Windows 2000" en la sección Referencia de esta guía.

Credenciales explícitas con autenticación básica o mediante Formularios

Como alternativa a la delegación Kerberos, puede utilizar la autenticación básica o mediante Formularios en la aplicación Web para capturar las credenciales del cliente y después utilizar la autenticación básica (o integrada de Windows) en el objeto remoto

Con este enfoque, las credenciales de texto no cifrado del cliente están disponibles para la aplicación Web. Éstas pueden transmitirse al objeto remoto mediante el proxy del objeto remoto. Para ello, deberá incluir código en la aplicación Web con el fin de recuperar las credenciales del cliente y configurar el proxy del objeto remoto.

Autenticación básica

Con la autenticación básica, las credenciales del llamador original se ponen a disposición de la aplicación Web en variables de servidor. El siguiente código muestra cómo recuperarlas y cómo configurar el proxy del objeto remoto.

// Retrieve client's credentials (available with Basic authentication)
   string pwd = Request.ServerVariables["AUTH_PASSWORD"];
   string uid = Request.ServerVariables["AUTH_USER"];
   // Associate the credentials with the remote object proxy
   IDictionary channelProperties = 
   ChannelServices.GetChannelSinkProperties(proxy);
   NetworkCredential credentials;
   credentials = new NetworkCredential(uid, pwd);
   ObjRef objectReference = RemotingServices.Marshal(proxy);
   Uri objectUri = new Uri(objectReference.URI);
   CredentialCache credCache = new CredentialCache();
   credCache.Add(objectUri, "Basic", credentials);
   channelProperties["credentials"] = credCache;
   channelProperties["preauthenticate"] = true;

Nota

Al constructor NetworkCredential del código anterior se le proporcionan el Id. de usuario y la contraseña. Para evitar tener que escribir en el código el nombre de dominio, puede configurarse un dominio predeterminado en el servidor Web desde IIS cuando se configura la autenticación básica.

Autenticación mediante Formularios

Con la autenticación mediante Formularios, las credenciales del llamador original se ponen a disposición de la aplicación Web en campos de formularios (en lugar de en variables de servidor). En este caso, utilice el código siguiente:

// Retrieve client's credentials from the logon form
   string pwd = txtPassword.Text;
   string uid = txtUid.Text;
   // Associate the credentials with the remote object proxy
   IDictionary channelProperties = 
   ChannelServices.GetChannelSinkProperties(proxy);
   NetworkCredential credentials;
   credentials = new NetworkCredential(uid, pwd);
   ObjRef objectReference = RemotingServices.Marshal(proxy);
   Uri objectUri = new Uri(objectReference.URI);
   CredentialCache credCache = new CredentialCache();
   credCache.Add(objectUri, "Basic", credentials);
   channelProperties["credentials"] = credCache;
   channelProperties["preauthenticate"] = true;

Las siguientes tablas contienen los pasos de configuración necesarios en el servidor Web y en el servidor de aplicaciones.

Configurar el servidor Web

Configurar IIS

Paso

Más información

Para utilizar la autenticación básica, deshabilite el acceso anónimo para el directorio raíz virtual de la aplicación Web y seleccione la autenticación básica
- o bien -
Para utilizar la autenticación mediante Formularios, habilite el acceso anónimo

La autenticación básica y mediante Formularios deben utilizarse conjuntamente con SSL para proteger las credenciales de texto no cifrado que se envían por la red. Si utiliza la autenticación básica, deberá utilizar SSL para todas las páginas (y no sólo la página de inicio de sesión inicial) porque se transmiten credenciales básicas con cada petición.
Asimismo, si usa la autenticación mediante Formularios, deberá utilizar SSL para todas las páginas para proteger las credenciales de texto no cifrado en el inicio de sesión inicial y para proteger también el vale de autenticación que se transmite en las peticiones posteriores.

Configurar ASP.NET

Paso

Más información

Si utiliza la autenticación básica, configure la aplicación Web ASP.NET para que utilice la autenticación de Windows
- o bien -
Si utiliza la autenticación mediante Formularios, configure la aplicación Web ASP.NET para que utilice la autenticación mediante Formularios

Edite el archivo Web.config en el directorio virtual de la aplicación Web.

Establezca el elemento <authentication> en:

<authentication mode="Windows" />

- o bien -
Edite el archivo Web.config en el directorio virtual de la aplicación Web.

Establezca el elemento <authentication> en:

<authentication mode="Forms" />

Deshabilitar la suplantación en la aplicación Web ASP.NET

Edite el archivo Web.config en el directorio virtual de la aplicación Web.

Establezca el elemento <identity> en:

<identity impersonate="false" />

Nota: equivale a no tener ningún elemento <identity>.

No se requiere la suplantación porque las credenciales del usuario se transmiten explícitamente al objeto remoto a través del proxy del mismo.

Configurar Remoting (proxy del cliente)

Paso

Más información

Configurar el proxy de remoting para que no utilice credenciales predeterminadas para todas las llamadas al objeto remoto

Agregue la siguiente entrada al archivo Web.config:

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

No debe permitir que se utilicen credenciales predeterminadas (puesto que la aplicación Web está configurada para no utilizar la suplantación, se utilizaría el contexto de seguridad de la identidad del proceso de ASP.NET).

Escribir código para capturar y establecer explícitamente las credenciales en el proxy del objeto remoto

Consulte los fragmentos de código mostrados anteriormente.

Configurar el servidor de aplicaciones

Configurar IIS

Paso

Más información

Deshabilitar el acceso anónimo para el directorio raíz virtual de la aplicación
Habilitar la autenticación básica

Nota: la autenticación básica en el servidor de aplicaciones (objeto remoto) permite al objeto remoto transmitir el contexto de seguridad del llamador original a la base de datos (porque el nombre de usuario y la contraseña del llamador están en texto no cifrado y pueden utilizarse para responder a desafíos de autenticación de red desde el servidor de bases de datos).

Si no necesita transmitir el contexto de seguridad del llamador original más allá del objeto remoto, considere la posibilidad de configurar IIS en el servidor de aplicaciones para que utilice la autenticación integrada de Windows, puesto que así se proporciona mayor seguridad (las credenciales no se transmiten por la red y no están disponibles para la aplicación).

Configurar ASP.NET (host del objeto remoto)

Paso

Más información

Configurar ASP.NET para que utilice la autenticación de Windows

Edite el archivo Web.config en el directorio virtual de la aplicación.

Establezca el elemento <authentication> en:

<authentication mode="Windows" />

Configurar ASP.NET para la suplantación

Edite el archivo Web.config en el directorio virtual de la aplicación.

Establezca el elemento <identity> en:

<identity impersonate="true" />

Nota: este paso sólo es necesario si desea transmitir el contexto de seguridad del llamador original por el objeto remoto hasta el siguiente subsistema de nivel inferior (como una base de datos). Al estar habilitada la suplantación, el acceso a recursos (locales y remotos) utiliza el contexto de seguridad del llamador original suplantado.

Si se requiere solamente permitir las comprobaciones de autorización por usuario en el objeto remoto, no es necesario utilizar la suplantación.

Subsistema de confianza

El modelo de subsistemas de confianza proporciona un enfoque alternativo (y es más sencillo de implementar) a la transmisión del contexto de seguridad del llamador original. En este modelo, existe un límite de confianza entre el host del objeto remoto y la aplicación Web. El objeto remoto confía en la aplicación Web para que autentique y autorice correctamente los llamadores antes de permitir que las peticiones se transmitan al objeto remoto. No se realiza la autenticación del llamador original en el host del objeto remoto. El host del objeto remoto autentica la identidad fija de confianza que utiliza la aplicación Web para comunicarse con el objeto remoto. Suele tratarse de la identidad del proceso de la aplicación Web ASP.NET.

El modelo de subsistemas de confianza se muestra en la ilustración 11.5. Este diagrama muestra además dos configuraciones posibles. La primera utiliza ASP.NET como host y el canal HTTP, mientras que la segunda usa un servicio de Windows como host y el canal TCP.

imagen

Ilustración 11.5

El modelo de subsistemas de confianza

Transmitir la identidad del llamador

Si utiliza el modelo de subsistemas de confianza, puede que todavía necesite transmitir la identidad del llamador original (el nombre, no el contexto de seguridad), como por ejemplo, para llevar a cabo una auditoría en la base de datos.
Puede transmitir la identidad en la aplicación mediante parámetros de métodos y de procedimientos almacenados y los parámetros de consulta de confianza (tal y como se muestra en el siguiente ejemplo) pueden utilizarse para recuperar datos específicos de usuario de la base de datos.

SELECT x,y,z FROM SomeTable WHERE UserName = "Bob"

Escoger un host

El modelo de subsistemas de confianza presupone que el host del objeto remoto no autentica los llamadores originales. No obstante, todavía debe autenticar (y autorizar) su cliente inmediato (la aplicación Web ASP.NET en este escenario) para impedir que aplicaciones no autorizadas emitan peticiones al objeto remoto.

Si utiliza ASP.NET como host y el canal HTTP, puede usar la autenticación integrada de Windows para autenticar la identidad del proceso de la aplicación Web ASP.NET.

Si utiliza un servicio de Windows como host, puede utilizar el canal TCP, que ofrece un mejor rendimiento, aunque sin capacidades de autenticación. En este escenario, puede utilizar IPSec entre el servidor Web y el servidor de aplicaciones. Puede establecerse una directiva IPSec que sólo permite al servidor Web comunicarse con el servidor de aplicaciones.

Pasos de configuración

Las siguientes tablas contienen los pasos de configuración necesarios en el servidor Web y en el servidor de aplicaciones.

Configurar el servidor Web

Configurar IIS

Paso

Más información

Configurar la autenticación de IIS

La aplicación Web puede utilizar cualquier forma de autenticación para autenticar los llamadores originales.

Configurar ASP.NET

Paso

Más información

Configurar la autenticación y comprobar que está deshabilitada la suplantación

Edite el archivo Web.config en el directorio virtual de la aplicación Web.

Establezca el elemento <authentication> en "Windows", "Forms" o "Passport".

<authentication mode="Windows|Forms|Passport" />

Establezca el elemento <identity> en:

<identity impersonate="false" />

(O quite el elemento <identity>.)

Restablecer la contraseña de la cuenta ASPNET utilizada para ejecutar ASP.NET O crear una cuenta de dominio con los mínimos privilegios para ejecutar ASP.NET y especificar información de cuenta en el elemento <processModel> del archivo Web.config

Para obtener más información acerca de cómo obtener acceso a recursos de red (incluidos los objetos remotos) desde ASP.NET y de cómo escoger y configurar una cuenta del proceso de ASP.NET, consulte "Obtener acceso a recursos de red" e "Identidad del proceso para ASP.NET" en el capítulo 8, "Seguridad de ASP.NET".

Configurar Remoting (proxy del cliente)

Paso

Más información

Configurar el proxy de remoting para que utilice credenciales predeterminadas para todas las llamadas al objeto remoto

Agregue la siguiente entrada al archivo Web.config:

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

Puesto que la aplicación Web no está utilizando la suplantación, el uso de credenciales predeterminadas hace que se utilice la identidad del proceso de ASP.NET para todas las llamadas al objeto remoto.

Configurar el servidor de aplicaciones

Si utiliza ASP.NET como host, siga los siguientes pasos:

Configurar IIS

Paso

Más información

Deshabilitar el acceso anónimo para el directorio raíz virtual de la aplicación
Habilitar la autenticación integrada de Windows

.

Configurar ASP.NET (host del objeto remoto)

Paso

Más información

Configurar ASP.NET para que utilice la autenticación de Windows

Edite el archivo Web.config en el directorio virtual de la aplicación.

Establezca el elemento <authentication> en:

<authentication mode="Windows" />

Deshabilitar la suplantación

Edite el archivo Web.config en el directorio virtual de la aplicación.

Establezca el elemento <identity> en:

<identity impersonate="false" />

Utilizar un servicio de Windows como host

Si utiliza un proceso de host del servicio de Windows, deberá crear una cuenta de Windows para ejecutar el servicio. El objeto remoto utilizará el contexto de seguridad proporcionado por esta cuenta para todos los accesos a recursos locales y remotos.Para obtener acceso a una base de datos de Microsoft SQL Server™ (mediante la autenticación de Windows), puede utilizar una cuenta de dominio con los mínimos privilegios o, al menos, una cuenta local con los mínimos privilegios y después crear una cuenta duplicada (con el mismo nombre de usuario y contraseña) en el servidor de bases de datos.

Comunicación segura

La comunicación segura se ocupa de garantizar la integridad y la confidencialidad de los mensajes durante su transmisión por la red. Puede utilizar un enfoque de plataforma para proteger la comunicación junto con SSL o IPSec, o utilizar un enfoque de mensaje y crear un receptor de cifrado personalizado para cifrar todo el mensaje o partes del mismo.

Opciones de plataforma

Las dos opciones de plataforma que debe considerar a la hora de proteger los datos que se transmiten entre un cliente y un componente remoto son:

  • SSL

  • IPSec

Si aloja objetos remotos en ASP.NET, puede utilizar SSL para proteger el canal de comunicación entre el cliente y el servidor. Requiere un certificado de autenticación de servidor en el equipo que aloja el objeto remoto.

Si aloja objetos remotos en un servicio de Windows, puede utilizar IPSec entre el equipo cliente y el equipo host (servidor), o crear un receptor de cifrado personalizado.

Opciones de mensaje

Gracias al carácter extensible de la arquitectura de .NET Remoting, puede desarrollar sus propios receptores personalizados y conectarlos a la canalización de procesamiento. Para proporcionar comunicación segura, puede desarrollar un receptor personalizado que cifra y descifra los datos de mensaje enviados al objeto remoto y desde él.

La ventaja de este enfoque reside en que le permite cifrar partes de un mensaje de forma selectiva. Se contrapone a los enfoques de plataforma que cifran todos los datos enviados entre el cliente y el servidor.

Más información

Para obtener más información acerca de SSL e IPSec, consulte el capítulo 4, "Comunicación segura".

Elegir un proceso de host

Los objetos a los que se va a obtener acceso de forma remota deben ejecutarse en un archivo ejecutable de host. El host atiende las peticiones entrantes y distribuye llamadas a los objetos. El mecanismo de transporte de mensajes (denominado canal) depende del tipo de host seleccionado. El tipo de canal seleccionado influye en las características de autenticación, autorización, comunicación segura y rendimiento de la solución.

El canal HTTP proporciona mejores opciones de seguridad, pero el canal TCP ofrece un mejor rendimiento.

Dispone de las siguientes opciones principales para alojar objetos remotos:

  • ASP.NET

  • Un servicio de Windows

  • Una aplicación de consola

Recomendación

Para sacar partido a la infraestructura de seguridad proporcionada por ASP.NET e IIS, desde el punto de vista de la seguridad, se recomienda alojar los objetos remotos en ASP.NET, lo que requiere que los clientes se comuniquen con los objetos remotos por el canal HTTP. Las características de autenticación, autorización y comunicación segura de ASP.NET e IIS están disponibles para los objetos remotos alojados en ASP.NET.

Si el factor principal es el rendimiento (y no la seguridad), considere la posibilidad de alojar los objetos remotos en servicios de Windows.

Utilizar ASP.NET como host

Cuando aloja un objeto remoto en ASP.NET:

  • El acceso al objeto se realiza con el protocolo HTTP.

  • Tiene un extremo al que puede obtener acceso una dirección URL.

  • Existe en un dominio de aplicación dentro del proceso de trabajo Aspnet_wp.exe.

  • Hereda las características de seguridad proporcionados por IIS y ASP.NET.

Ventajas

Si aloja objetos remotos en IIS, dispondrá de las siguientes ventajas:

  • Las características de autenticación, autorización y comunicación segura proporcionadas por IIS y ASP.NET están disponibles de forma inmediata.

  • Puede utilizar las características de auditoría de IIS.

  • El proceso de trabajo de ASP.NET se ejecuta de forma constante.

  • Dispone de un alto nivel de control sobre el ejecutable de host gracias al elemento <processModel> del archivo Machine.config. Puede controlar la administración de subprocesos, la tolerancia a errores, la administración de la memoria, etc.

  • Puede crear una capa de servicios Web delante del objeto remoto.

Desventajas

Si utiliza ASP.NET para alojar objetos remotos, deberá tener en cuenta las siguientes desventajas:

  • Requiere el uso del canal HTTP, que es más lento que el canal TCP.

  • ASP.NET no carga los perfiles de usuario. Hay varias técnicas de cifrado (como DPAPI) que podrían requerir perfiles de usuario.

  • Podría tener que utilizar la autenticación básica si se obtiene acceso al objeto desde código en ejecución en una aplicación Web ASP.NET.

Utilizar un servicio de Windows como host

Cuando se aloja un objeto remoto en un servicio de Windows, el objeto remoto se ubica en un dominio de aplicación del proceso del servicio. No se puede utilizar el canal HTTP, por lo que deberá utilizar el canal TCP. El canal TCP admite las siguientes características de seguridad:

  • Características de autenticación
    Debe proporcionar una solución de autenticación personalizada. Dispone de las siguientes opciones:

    • Utilizar los servicios de autenticación subyacentes de SSPI. Puede crear un receptor de canales que utiliza la credencial SSPI de Windows y APIs de administración de contextos para autenticar el llamador y, de forma opcional, suplantarlo. El receptor de canales está situado sobre el canal TCP. SSPI junto con el canal TCP permite el intercambio de información de autenticación entre el cliente y el servidor. Tras la autenticación, el cliente y el servidor pueden enviar mensajes sin poner en peligro su confidencialidad e integridad.

    • Utilizar un transporte subyacente que admite la autenticación, como por ejemplo, las canalizaciones con nombre. El canal de canalizaciones con nombre utiliza canalizaciones con nombre como mecanismo de transporte. Así, se permite realizar la autenticación del llamador, y se utilizan además la seguridad basada en ACL de Windows en la canalización y la suplantación del llamador.

  • Características de autorización

    Sólo puede llevar a cabo la autorización si implementa una solución de autenticación personalizada.

    • Si puede suplantar al usuario (por ejemplo, mediante un transporte de canalizaciones con nombre subyacente), puede utilizar WindowsPrincipal.IsInRole.

    • Si puede crear un objeto IPrincipal para representar al cliente autenticado, puede utilizar funciones de .NET (mediante peticiones de permisos de principales y comprobaciones de funciones explícitas con IPrincipal.IsInRole).

  • Características de comunicación segura

    Dispone de dos opciones:

    • Utilizar IPSec para proteger el transporte de datos entre el cliente y el servidor

    • Crear un receptor de canales personalizado que realice el cifrado asimétrico. Esta opción se describe más adelante en este capítulo.

Ventajas

Si aloja objetos remotos en servicios de Windows, dispondrá de las siguientes ventajas:

  • Gran control de activación sobre el proceso de host.

  • Hereda las ventajas de la arquitectura de servicios de Windows.

  • No es necesario introducir IIS en el nivel medio de la aplicación.

  • Los perfiles de usuario se cargan automáticamente.

  • El rendimiento es bueno, puesto que los clientes se comunican por el canal TCP mediante datos con codificación binaria.

Desventajas

Si utiliza un servicio de Windows para alojar objetos remotos, deberá tener en cuenta las siguientes desventajas:

  • Debe proporcionar soluciones de autenticación y autorización personalizadas.

  • Debe proporcionar soluciones de comunicación segura.

  • Debe proporcionar soluciones de auditoría.

Utilizar una aplicación de consola como host

Cuando se aloja un objeto remoto en una aplicación de consola, el objeto remoto se ubica en un dominio de aplicación del proceso de la aplicación de consola. No se puede utilizar el canal HTTP, por lo que deberá utilizar el canal TCP.

No se recomienda este enfoque para soluciones de producción.

Ventajas

Este enfoque tiene muy pocas ventajas, aunque sí implica que no sea necesario el uso de IIS en el nivel medio. No obstante, este enfoque sólo se recomienda para el desarrollo y las pruebas, y no para entornos de producción.

Desventajas

Si aloja objetos remotos en un archivo ejecutable personalizado, deberá tener en cuenta las siguientes desventajas:

  • El host debe iniciarse de forma manual y se ejecuta bajo la sesión de inicio interactiva (no recomendado).

  • No existe tolerancia a errores.

  • Debe proporcionar autenticación y autorización personalizadas.

  • No existe capacidad de auditoría.

Remoting y servicios Web

.NET ofrece muchas técnicas distintas para permitir la comunicación de los clientes con objetos remotos, como el uso de servicios Web.

Si necesita interoperabilidad entre sistemas heterogéneos, la mejor opción consiste en utilizar un enfoque de servicios Web que use estándares abiertos como SOAP, XML y HTTP. Por otro lado, si crea soluciones de intranet de servidor a servidor, remoting ofrece las siguientes características:

  • Buena fidelidad de objetos, porque se puede utilizar remoting con cualquier tipo de .NET (incluidos los tipos personalizados creados con la herramienta de desarrollo Microsoft C#® y el sistema de desarrollo Microsoft Visual Basic® .NET).
    Entre ellos, figuran las clases, jerarquías de clases, interfaces, campos, propiedades, métodos y delegados, conjuntos de datos, tablas de hash, etc.

  • Los objetos pueden resolverse por valor y por referencia.

  • La administración de la duración de los objetos se basa en concesiones.

  • Alto rendimiento, especialmente con el canal TCP y el formateador binario.

  • Permite crear niveles medios con cargas equilibradas mediante el equilibrio de carga de red.

Tabla 11.2: Diferencias principales entre remoting y los servicios Web

Remoting

Servicios Web

Administración de la duración de los objetos basada en concesiones con estado o sin estado

Todas las llamadas de método son sin estado

No es necesario utilizar IIS.(No obstante, se recomienda el alojamiento en IIS/ASP.NET por motivos de seguridad.)

IIS debe estar instalado en el servidor.

Se admiten todos los tipos administrados.

Se admiten tipos de datos limitados. Para obtener más información acerca de los tipos admitidos por los servicios Web ASP.NET, consulte ".NET Framework Developer's Guide" (en inglés) en MSDN.

Los objetos pueden transmitirse por referencia o por valor.

No se pueden transmitir objetos.

Contiene una arquitectura extensible y no limitada a los transportes HTTP o TCP.

Limitados a XML sobre HTTP

Pueden conectarse receptores de procesamiento personalizados en la canalización de procesamiento de mensajes.

No se pueden modificar los mensajes.

La implementación de SOAP es limitada y sólo puede utilizar la codificación RPC.

La implementación de SOAP puede utilizar la codificación RPC o de documentos y puede interoperar a la perfección con otras plataformas de servicios Web.
Para obtener más información, consulte la sección "Message Formatting and Encoding" del artículo "Distributed Application Communication" (en inglés) en MSDN.

Alta integración

Baja integración

Conclusión

.NET Remoting no dispone de su propio modelo de seguridad. No obstante, al alojar los objetos remotos en ASP.NET y utilizar el canal HTTP para la comunicación, los objetos remotos pueden utilizar los servicios de seguridad subyacentes proporcionados por IIS y ASP.NET. En comparación, el uso del canal TCP y un archivo ejecutable de host personalizado ofrece un mejor rendimiento, pero no proporciona seguridad integrada.

  • Si desea autenticar el cliente, utilice el canal HTTP, ASP.NET como host y deshabilite el acceso anónimo en IIS.

  • Utilice el canal TCP para obtener un mejor rendimiento si no necesita autenticar el cliente.

  • Utilice IPSec para proteger el canal de comunicación entre el cliente y el servidor si usa el canal TCP. Utilice SSL para proteger el canal HTTP.

  • Si necesita realizar llamadas de confianza a un recurso remoto, aloje el componente en un servicio de Windows y no en una aplicación de consola.

  • Los objetos IPrincipal no se transmiten por límites de .NET Remoting. Deberá considerar la posibilidad de implementar su propia clase IPrincipal que se pueda serializar. En ese caso, tenga en cuenta que para un cliente avispado resultaría relativamente sencillo falsificar un objeto IPrincipal y enviarlo al objeto remoto. Tenga cuidado también con IlogicalThreadAffinitive si implementa su propia clase IPrincipal para remoting.

  • Nunca exponga objetos remotos en Internet. Utilice servicios Web para este escenario.
    .NET Remoting sólo debe utilizarse en la intranet. El acceso a los objetos debe realizarse desde aplicaciones Web internas. Incluso si un objeto está alojado en ASP.NET, no lo exponga a clientes de Internet, puesto que los clientes tendrían que ser clientes de .NET.

Mostrar:
© 2015 Microsoft