Este artículo proviene de un motor de traducción automática.

Seguridad de Silverlight

Proteger sus aplicaciones de Silverlight

Josh Twist

En mi función como consultor de servicios de Microsoft, tengo regulares las conversaciones con clientes y asociados de negocios acerca de la seguridad de las aplicaciones. En este artículo, explicaré algunos de los temas que surgen en dichas discusiones. En concreto, me centraré en los nuevos desafíos que enfrentan los programadores al intentar proteger las aplicaciones de Silverlight y considere a la posibilidad de donde los equipos de desarrollo deben concentrar sus recursos.

En este artículo se mencionan en muchos conceptos técnicos que encontrará trata con más detalle en otro lugar (incluyendo esta revista). Por este motivo, no explore estos temas en gran profundidad técnica. En su lugar, el objetivo del artículo es “conectar los puntos” y mostrar cómo puede aprovechar estos conceptos para proteger las aplicaciones.

Al planear la seguridad para una aplicación, es útil considerar de tres A: autenticación, autorización y auditoría.

Autenticación es el acto de confirmar que los usuarios son quienes dicen ser. Normalmente ello con un nombre de usuario y una contraseña.

Autorización es el proceso de confirmar que un usuario, una vez autenticado, en realidad tiene permisos adecuados realizar una acción concreta o tener acceso a un recurso determinado.

Auditoría es el acto de mantener un registro de actividad de tal forma que no se denegará las acciones y las solicitudes realizadas en un sistema por el usuario.

Me centraré en los dos primeros, autenticación y autorización, en el contexto de una aplicación de Silverlight. Como es una aplicación de Internet enriquecidas (RIA), la mayoría de los conceptos descritos en este artículo aplican por igual a JavaScript asincrónico y XML (AJAX) o otro RIA enfoques. También explicaré cómo impedir el acceso no deseado a los archivos de aplicación de Silverlight.

Topología

Silverlight es un exploradores complemento que aprovecha muchos de los conceptos gráficos sido pionera por Windows Presentation Foundation (WPF), lo que permite a los desarrolladores Web crear experiencias de usuario enriquecida mucho más allá de lo que es posible sólo con HTML y JavaScript.

A diferencia de ASP.NET, Silverlight es una tecnología de cliente, para que se ejecute en equipos de los usuarios ’. Desarrollo de Silverlight posiblemente tendrá más en común con formularios Windows Forms o WPF que con ASP.NET. En muchos sentidos, ésta es una mayores ventajas de Silverlight, como quita muchos de los problemas causados por la naturaleza sin estado de las aplicaciones Web. No sin embargo, debido a que se ejecuta el código de interfaz de usuario en los equipos cliente, puede confiar en él ya.

Servicios

A diferencia de los formularios Windows Forms, Silverlight funciona dentro del recinto de seguridad de explorador y tiene un conjunto reducido de capacidades, por lo que proporciona un mayor grado de seguridad (aunque en el 4 de Silverlight, los usuarios pueden identificar determinadas aplicaciones como de confianza y promover privilegios ’ programas para permitir la interoperabilidad COM). A causa de esto, Silverlight no se puede conectar con una base de datos directamente, por lo tanto, debe crear una capa de servicios que proporcionan acceso a su datos y la lógica empresarial.

Normalmente, se host estos servicios en el servidor Web, al igual que harían con los formularios ASP.NET Web for example. Dado que el código de Silverlight se ejecuta en el lado incorrecto de los límites de confianza entre los servidores y el mundo real (consulte La figura 1), siempre debe ser el enfoque de esfuerzo del equipo proteger los servicios.

Figura 1 Silverlight se ejecuta en el lado incorrecto de límite de confianza

No hay punto poco en la implementación de comprobaciones de seguridad rigurosa en su propio código de Silverlight. Una vez todos los, sería fácil para que un atacante hacer inmediatamente con la aplicación de Silverlight por completo y invocar directamente los servicios, stepping lado alguna seguridad de las medidas implementadas. Como alternativa, una persona malintencionada podría utilizar una utilidad como Spy de Silverlight o herramientas de depuración para Windows para cambiar el comportamiento de la aplicación en tiempo de ejecución.

Se trata de una realización importante: un servicio no puede saber con seguridad qué aplicación está invocando o que la aplicación no se ha modificado de alguna manera. Por lo tanto los servicios tiene que asegurarse de que:

• El llamador se autentica correctamente
• El llamador está autorizado para realizar la acción solicitada

Por estas razones, la mayor parte de este artículo se centra en cómo proteger los servicios de forma que es compatible con Silverlight. En concreto, podrá tener en cuenta dos tipos diferentes de servicios alojados a través de ASP.NET en IIS de Microsoft. El primer tipo, los servicios creados mediante Windows Communication Foundation (WCF) proporciona un modelo de programación unificado para crear servicios. El segundo, WCF Data Services (anteriormente ADO.NET Data Services), se basa en WCF le permiten exponer rápidamente datos con los verbos HTTP estándar, un método conocido como transferencia de estado de representación (REST).

Naturalmente, si la seguridad es una preocupación, siempre es aconsejable cifrar cualquier comunicación entre clientes y servidores. Se recomienda el uso de HTTPS/SSL cifrado y supone a lo largo de este artículo.

En la actualidad, los dos métodos de autenticación más comunes a los desarrolladores Web utilizan en la plataforma de Microsoft son la autenticación de Windows y autenticación de formularios.

Autenticación de Windows

Autenticación de Windows aprovecha la autoridad de seguridad local o Active Directory para validar las credenciales del usuario. Se trata de una gran ventaja en muchos escenarios; significa que puede administrar de forma centralizada los usuarios con herramientas ya están familiarizados los administradores de sistemas. La autenticación de Windows puede utilizar cualquier esquema compatible con IIS incluidos básica, implícita, autenticación integrada (NTLM/Kerberos) y certificados.

El esquema integrado es la elección más común para su uso con autenticación de Windows, porque los usuarios no tienen que proporcionen sus nombres de usuario y contraseñas de una segunda vez. Una vez que un usuario inicia sesión en Windows, el explorador puede reenviar credenciales en forma de un símbolo (token) o un enlace que confirma la identidad de la persona. Existen algunos inconvenientes mediante la autenticación integrada, porque el cliente y el servidor necesitan visibilidad de dominio del usuario. Como resultado, mejor está dirigido a escenarios de intranet. Además, aunque funciona con Microsoft Internet Explorer automáticamente, otros exploradores, como Mozilla Firefox, requieren configuración adicional.

Ambos básico y la autenticación implícita normalmente requieren que los usuarios volver a introducir sus nombres de usuario y contraseñas cuando inician una sesión con su sitio Web. Pero puesto que ambos forman parte de la especificación de HTTP, funcionan en la mayoría de los exploradores y incluso cuando se tiene acceso desde fuera de su organización.

Silverlight aprovecha el Explorador de comunicación, para que la autenticación de Windows sea más fácil de implementar con cualquiera de los métodos de autenticación de IIS que acabamos de explicar. Para obtener una descripción detallada de cómo hacerlo, se recomienda leer la Guía paso a paso “ How to: Utilizar basicHttpBinding con autenticación de Windows y TransportCredentialOnly en WCF desde los formularios Windows Forms ” en MSDN.Microsoft.com/library/cc949012. En este ejemplo se utiliza realmente un cliente de prueba de Windows Forms, pero se aplica el mismo enfoque para Silverlight.

Autenticación mediante formularios

La autenticación mediante formularios es un mecanismo que proporciona compatibilidad con simple para la autenticación personalizada en ASP.NET. Como tal, es específica de HTTP, lo que significa que también es fácil de usar en Silverlight.

El usuario introduce una combinación de nombre de usuario y contraseña, que se presenten al servidor para su comprobación. El servidor comprueba las credenciales con respecto a un origen de datos de confianza (a menudo una base de datos de usuarios) y si es correctos, devuelve una cookie de FormsAuthentication. A continuación, el cliente presenta este cookie con las solicitudes posteriores. La cookie se firmados y cifrada, lo sólo el servidor puede descifrar: un usuario malintencionado puede descifrar ni altere a él.

Exactamente cómo invocación autenticación mediante formularios varía en función de cómo implementar la pantalla de inicio de sesión. Por ejemplo, si ha utilizado un formulario Web de ASP.NET que redirige a la aplicación de Silverlight una vez validadas las credenciales del usuario, probablemente tiene trabajo de autenticación no hay más que hacer. La cookie ya se han enviado al explorador y la aplicación de Silverlight seguirá utilizan la cookie siempre que realizar una solicitud a ese dominio.

Si desea implementar la pantalla de inicio de sesión dentro de la aplicación de Silverlight, es necesario crear un servicio que expone los métodos de autenticación y envía la cookie correspondiente. Afortunadamente, ASP.NET proporciona ya lo que necesita, el servicio de autenticación. Sólo necesita habilitarla en la aplicación. Para obtener instrucciones detalladas, recomiendo leer “ How to: Utilizar el servicio de autenticación de ASP.NET para iniciar sesión en a través de aplicaciones de Silverlight ” en MSDN.Microsoft.com/library/dd560704(VS.96).

Otra gran característica de autenticación de ASP.NET es su extensibilidad. Un proveedor de suscripciones describe el mecanismo mediante el cual se comprueba la el nombre de usuario y contraseña. Afortunadamente, hay una serie de proveedores de suscripciones disponibles como parte de ASP.NET, incluido el que puede utilizar las bases de datos de SQL Server y otro que utiliza Active Directory. No obstante, si un proveedor que cumple el requisito no está disponible, es sencillo crear una implementación personalizada.

Autorización de ASP.NET

Una vez se autentican los usuarios, es importante garantizar que sólo puede intentar invocar los servicios. Tanto los servicios de WCF y servicios de datos de WCF ordinario se representan mediante un archivo .svc en aplicaciones ASP.NET. En este ejemplo, se van a los servicios que se va a alojar a través de ASP.NET en IIS y podrá demostrar cómo se pueden utilizar carpetas para proteger el acceso a los servicios.

Proteger archivos .svc de esta forma es un poco confusa porque, de forma predeterminada, una petición de dicho archivo omite realmente la mayor parte de la canalización de ASP.NET, omitiendo los módulos de autorización. Como resultado, para poder dependen de muchas características ASP.NET, tendrá que habilitar el modo de compatibilidad ASP.NET. En cualquier caso, los servicios de WCF de datos exigen que la habilite. Un simple conmutador dentro de su archivo de configuración logra la tarea:

<system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
</system.serviceModel>
<system.web>
    <authorization>
        <deny users="?"/>
    </authorization>
</system.web>

Con compatibilidad con ASP.NET habilitado, es posible evitar el acceso a los usuarios no autenticados mediante la sección autorización de un archivo web.config, que también se muestra en el fragmento de código anterior.

Cuando se utiliza la autenticación de formularios, el desarrollador debe considerar cuidadosamente sobre qué partes del sitio deben ser accesibles, incluso a los usuarios no autenticados. ¿Por ejemplo, si todas las partes están restringidas a los usuarios autenticados sólo, cómo un usuario no autenticado registrará?

A menudo es más fácil crear una estructura de carpetas que soporte los requerimientos de autorización básica. En este ejemplo, he creado una carpeta de “ asegurado ” que contiene los archivos MyWcfService.svc y MyWcfDataService.svc y he implementado un archivo web.config. In Figura 2 puede ver la estructura de carpetas y el fragmento de código anterior muestra el contenido del archivo web.config.

Figura 2 Carpeta segura que contiene el archivo Web.config

Tenga en cuenta que la raíz de la aplicación debe tener acceso anónimo permitido, en caso contrario, los usuarios no podrán llegar a la página de inicio de sesión.

Para los sitios mediante la autenticación de Windows, las cosas pueden ser algo más sencillas a este respecto, como autenticación tiene lugar antes de que el usuario obtiene los recursos contenido dentro de la aplicación, por lo tanto no es necesario para una página de inicio de sesión específico. Con este enfoque, es realmente posible restringir el acceso a servicios de una forma más detallada, lo que permite que a sólo determinados grupos de usuarios o funciones para tener acceso a los recursos. Para obtener más información, consulte “ autorización de ASP.NET ” (msdn.microsoft.com/library/wce3kxhd).

En este ejemplo implementa autorización algo, pero por sí sola la autorización de nivel de carpeta es demasiado amplio confiar en la mayoría de los escenarios.

Autorización en los servicios WCF

Mediante el atributo PrincipalPermission es una forma fácil a la demanda un invocador de un método de Microsoft .NET Framework estar dentro de una función específica. En este ejemplo de código se muestra cómo esto podría aplicarse a ServiceOperation en donde el usuario realiza la llamada debe ser parte de la función de “ OrderApprovers ” de WCF:

[PrincipalPermission(SecurityAction.Demand, Role = "OrderApprovers")]
public void ApproveOrder(int orderId)
{
  OrderManag-er.ApproveOrder(orderId);
}

Se implementa fácilmente en las aplicaciones que utilizan autenticación de Windows para aprovechar la instalación existente para crear grupos de Active Directory para organizar los usuarios. Con aplicaciones que utilizan la autenticación mediante formularios, es posible aprovechar otra gran característica basadas en proveedor de ASP.NET: RoleProviders. De nuevo, hay un número de estos disponibles, pero si ninguno son adecuado, puede implementar su propia.

Por supuesto, incluso por método autorización es rara vez suficiente para satisfacer su seguridad necesita y retroceder siempre a escribir el código del procedimiento dentro de sus servicios tal y como se muestra en Figura 3.

Figura 3 Utilizando código de procedimiento para implementar autorización específica

Public void CancelOrder(int orderId)
{
  // retrieve order using Entity Framework ObjectContext
  OrdersEntities entities = new OrdersEntities();
  Order orderForProcessing = entities.Orders.Where(o => o.Id == 
    orderId).First();

  if (orderForProcessing.CreatedBy != 
    Thread.CurrentPrincipal.Identity.Name)
  {
    throw new SecurityException(
      "Orders can only be canceled by the user who created them");
  }

  OrderManager.CancelOrder(orderForProcessing);
}

WCF es una plataforma altamente ampliable y como ocurre con todas las cosas en WCF, hay muchos enfoques para implementar la autorización en sus servicios. Dominick Baier y Christian Weyer tratan un número de posibilidades en detalle en el número de octubre de 2008 de MSDN Magazine. El artículo “ autorización en WCF-Based servicios ” (MSDN.Microsoft.com/magazine/cc948343), incluso asociaciones temporales en la seguridad basada en solicitudes, una manera estructurada de organizar la autorización en la aplicación.

Autorización en servicios de datos WCF

WCF Data Services, como el nombre sugiere, se basa en WCF para proporcionar acceso basado en REST a un origen de datos, quizás más a menudo un origen de datos LINQ para SQL o LINQ a Entity Framework. En resumen, esto permite proporcionar acceso a sus datos mediante una dirección URL que se asigna a los conjuntos de entidad expuestos por el origen de datos (un conjunto de entidades asigna normalmente a una tabla en la base de datos). Se pueden configurar permisos para estos conjuntos de entidades dentro del archivo de código subyacente de servicios. Figura 4 muestra el contenido del archivo MyWcfDataService.svc.cs.

Figura 4 Reglas de acceso set de un archivo de código subyacente de servicios WCF datos con la configuración de entidad

Public class MyWcfDataService : DataService<SalesEntities>
{
  // This method is called only once to initialize service-wide policies.
  Public static void InitializeService(IDataServiceConfiguration config)
  {
    config.SetEntitySetAccessRule("Orders", EntitySetRights.AllRead);
    config.SetEntitySetAccessRule("Products", EntitySetRights.AllRead | 
      EntitySetRights.WriteAppend | EntitySetRights.WriteDelete);
  }}

En este caso, he dado permisos de lectura en el conjunto de entidades Orders y configurado la entidad de productos se establece para permitir completa leer, insertar nuevos registros y registra la eliminación de los existentes.

Sin embargo, debido a que WCF Data Services presenta automáticamente el acceso a los datos basándose en esta configuración, no tienes acceso directo a código, por lo que no hay ningún lugar obvia para implementar cualquier lógica de autorización específica. WCF Data Services admite interceptores que permiten a los desarrolladores implementar lógica entre el cliente y el origen de datos. Por ejemplo, es posible especificar un interceptor de consulta que filtra los resultados para un conjunto concreto de entidad. En el ejemplo de Figura 5 muestra dos interceptores de consulta de agregado a la clase MyWcfDataService.

Figura 5 Consulta interceptores en WCF Data Services

[QueryInterceptor("Products")]
Public Expression<Func<Product, bool>> OnQueryProducts()
{
  String userName =ServiceSecurityContext.Current.PrimaryIdentity.Name;
  return product => product.CreatedBy == userName;
}

[QueryInterceptor("Orders")]
Public Expression<Func<Comments, bool>> OnQueryOrders()
{
  bool userInPrivateOrdersRole = 
    Thread.CurrentPrincipal.IsInRole("PrivateOrders");
  return order => !order.Private|| userInPowerUserRole;
}

El primero se aplica a los productos entidad establecido y garantiza que los usuarios pueden recuperar sólo los productos creados por ellos. El segundo garantiza que sólo los usuarios de la función PrivateOrders pueden leer pedidos marcan Private.

Del mismo modo, es posible especificar interceptores de cambio que se ejecutan antes de una entidad se inserta, modifica o elimina como se muestra a continuación:

[ChangeInterceptor("Products")]
public void OnChangeProducts(Product product, UpdateOperations operations
{
  if (product.CreatedBy != Thread.CurrentPrincipal.Identity.Name)
  {
    throw new DataServiceException(
      "Only products created by a user can be deleted by that user");
  }
}

En visualización inicial, el interceptor de cambio OnChangeProducts en este ejemplo de código aparece exponer una vulnerabilidad de seguridad, ya que la implementación se basa en datos pasados desde un origen externo, específicamente el parámetro “ producto ”. Pero cuando se elimina una entidad en los servicios de WCF de datos, se pasa una clave de entidad desde el cliente al servidor. Que significa el producto de la entidad en sí mismo, en este caso, tiene que recuperarse de la base de datos y, por lo tanto, se puede confiar.

Sin embargo, en el caso de una actualización de una entidad existente (por ejemplo, cuando el parámetro de operaciones es igual a UpdateOperations.Change), el parámetro de producto es la entidad deserializada enviada por el cliente, por lo tanto, no puede ser confianza. La aplicación cliente puede haberse modificada para especificar la propiedad CreatedBy de este producto concreto a una identidad malintencionado propia del usuario, con lo que se eleven privilegios del usurper. Que podría permitir la modificación de un producto de forma individual que no debería poder hacerlo. Para evitar esto, recomiendo re-fetch la entidad original desde el origen de datos de confianza según la clave de entidad por sí solo, tal y como se muestra en Figura 6.

Figura 6 Un interceptor cambiar cómo evitar Unauthorized INSERT, Update y eliminar operaciones

[ChangeInterceptor("Products")]
Public void OnChangeProducts(Product product, UpdateOperations operations)
{
  if (operations == UpdateOperations.Add)
  {
    product.CreatedBy = Thread.CurrentPrincipal.Identity.Name;
  }
  else if (operations == UpdateOperations.Change)
  {
    Product sourceProduct = this.CurrentDataSource.Products.Where(p =>
      p.Id == product.Id).First();
    if (sourceProduct.CreatedBy != Thread.CurrentPrincipal.Identity.Name)
    {
      throw new DataServiceException(
        "Only records created by a user can be modified by that user");
    }
  }
  else if (operations == UpdateOperations.Delete &&
    product.CreatedBy != Thread.CurrentPrincipal.Identity.Name)
  {
    Throw new DataServiceException(
      "Only records created by a user can be deleted by that user");
  }
}

Ya que esta implementación basa tanto en la propiedad CreatedBy de la entidad de producto, es muy importante que esto se aplica de forma segura desde el momento en que los datos se crean. Figura 6 muestra también cómo esto puede lograrse reemplazando cualquier valor pasado por el cliente para una operación de agregar.

Tenga en cuenta que tal como actualmente está en el ejemplo, control de operaciones de tipo UpdateOperations.Change no es un problema. In Figura 4, el servicio se ha configurado para permitir sólo AllRead, WriteAppend (Insertar) y WriteDelete acciones ocurren en conjuntos de entidades de productos. Por lo tanto, el ChangeInterceptor no sería nunca necesario invocar una operación de cambio, como el servicio rechazaría inmediatamente cualquier solicitud para modificar una entidad de producto en este extremo. Para habilitar las actualizaciones, la llamada a SetEntitySetAccessRule en Figura 4 tendría que incluir WriteMerge, WriteReplace o ambos.

Autenticación de dominios interrelacionados

El complemento Silverlight puede realizar las solicitudes HTTP de dominios interrelacionados. Una llamada entre dominios es una solicitud HTTP realizada a un dominio distinto de aquél del que se descargó la aplicación de Silverlight. La capacidad de realizar tales llamadas tradicionalmente ha sido ver como una vulnerabilidad de seguridad. Permitiría que un desarrollador malintencionado realizar solicitudes a otro sitio (por ejemplo, su sitio de banca en línea) y reenviar automáticamente las cookies asociadas a ese dominio. Potencialmente, esto podría dan acceso al atacante a otra sesión inicio de sesión dentro del mismo proceso de explorador.

Por este motivo, los sitios tienen optar por permitir que las llamadas entre dominios a través de la implementación de un archivo de directivas cross-domain. Esto es un archivo XML que describe qué tipos de las llamadas entre dominios se permiten, por ejemplo, de qué dominio a qué direcciones URL. Para obtener más información, consulte “ Making a Service Available Across Domain Boundaries ” (msdn.microsoft.com/library/cc197955(VS.95)).

Se deben tener siempre cuidado cuando decida exponer cualquier información confidencial a las llamadas entre dominios. Pero si decide que se trata de un escenario tiene que admitir junto con la autenticación, es importante destacar que la autenticación basada en cookies métodos, como la autenticación de formularios se ha descrito anteriormente: ya no son adecuados. En su lugar, puede considerar la posibilidad de aprovechar las credenciales de mensaje, donde el nombre de usuario y contraseña se pasa al servidor y validados con cada llamada. WCF admite esto a través del modo de seguridad TransportWithMessageCredential. Para obtener más información, consulte “ How to: Usar credenciales de mensajes para proteger un servicio para aplicaciones de Silverlight ” (MSDN.Microsoft.com/library/dd833059(VS.95)).

Por supuesto, este enfoque quita ASP.NET el proceso de autenticación por completo, por lo que resulta difícil aprovechar junto con authorization ASP.NET, que se ha explicado anteriormente.

Proteger los archivos XAP de Silverlight

Personas que preocupa a Silverlight seguridad suelen preguntar, “ ¿cómo puedo proteger Mis archivos XAP? ” A veces, la motivación para esta consulta es proteger la propiedad intelectual contenida en el código. En este caso, deberá mirar ofuscación para que sea más difícil para las personas a comprender el código.

Otra motivación común es evitar que usuarios malintencionados de interrogación del código y saber cómo funciona la aplicación de Silverlight, dándoles la posibilidad de interrumpir sus servicios.

Suele responder a esto con dos puntos. En primer lugar, aunque es posible restringir la descarga de la aplicación de Silverlight (archivo .xap) a usuarios autenticados y autorizados, no hay ninguna razón para confiar en estos los usuarios sean menos cualquier malintencionado que un usuario no autenticado. Una vez descargada la aplicación al cliente, no hay absolutamente nada para detener a los usuarios de interrogación del código en un intento de aumentar sus propios privilegios o reenviar las bibliotecas a otro usuario. Ofuscación puede hacer que este proceso un poco más difícil, pero no es bastante buena como para hacer que una aplicación sea segura.

En segundo lugar, es muy importante recordar que cualquier persona que puede llamar legítimamente a servicios a través de la aplicación de Silverlight puede llamar también a dichos servicios directamente, utilizando un explorador de Internet y algunos JavaScript, por ejemplo. No hay nada que puede hacer para que esto no sucede, por lo que es primordial centrar los esfuerzos de seguridad en shoring hasta sus servicios. Realice este derecho y no importa lo que un usuario malintencionado puede obtener desde código de la aplicación de Silverlight. No obstante, algunas personas todavía le gustaría asegurarse de que sólo los usuarios autenticados pueden tener acceso a sus archivos .xap. Esto es posible, pero lo fácil que es depende de la versión de IIS que utiliza y el método de autenticación seleccionado.

Si utiliza la autenticación de Windows, puede proteger fácilmente los archivos de .xap mediante seguridad de directorios de IIS. Si, sin embargo, está usando autenticación de formularios, puede ser un poco más complicado. En este caso, resulta FormsAuthenticationModule para interceptar y compruebe la cookie que acompañan a cualquier solicitud y permitir o denegar el acceso al recurso solicitado.

Debido a que FormsAuthenticationModule es un módulo de ASP.NET, la solicitud debe pasar a través de la canalización de ASP.NET de esta inspección tienen lugar. En IIS 6 (Windows Server 2003) y versiones anteriores, las solicitudes para los archivos .xap no, lo hará de forma predeterminada, enrutarse a través de ASP.NET.

IIS7 (Windows Server 2008), sin embargo, introdujo la canalización integrada de todas las solicitudes que deben enrutarse a través de la canalización de ASP.NET. Si puede implementar en IIS7 y utiliza un grupo de aplicaciones que se ejecutan en modo de canalización integrada, proteger los archivos .xap no es más difícil de proteger los archivos .svc como se ha descrito anteriormente en la sección autorización de ASP.NET. Pero si tiene que implementar en IIS 6 o versiones anteriores, probablemente tenga algún trabajo adicional que hacer.

Un enfoque más popular implica la transmisión por secuencias de bytes que componen el archivo .xap a través de otra extensión maneja la canalización de ASP.NET. La manera habitual para ello es a través de una implementación IHttpHandler (en un archivo .ashx). Para obtener más información consulte “ Introducción a controladores HTTP ” (MSDN.Microsoft.com/library/ms227675(VS.80)).

Otro enfoque es cambiar la configuración de IIS para que los archivos .xap se enrutan a través de la canalización de ASP.NET. Sin embargo, dado que requiere un cambio no trivial en la configuración de IIS, el enfoque anterior es más común.

Otro problema que se deben tener en cuenta con la autenticación de formularios es la pantalla de inicio de sesión. Si, como propuesto anteriormente en este artículo, optan por un formulario Web de ASP.NET, no hay ningún problema. Pero si prefiere la pantalla de inicio de sesión para ser creados en Silverlight, deberá dividir la aplicación en partes. Una parte (el módulo de inicio de sesión) debe estar disponible para los usuarios no autenticados y otra (la aplicación protegida) debe estar disponible para los usuarios autenticados sólo.

Puede tomar dos enfoques:

1. Dispone de dos aplicaciones de Silverlight independientes. La primera sería contain el cuadro de diálogo de inicio de sesión y estar en un área no seguro del sitio. Durante el inicio de sesión con éxito, esto podría, a continuación, redirigir a una página especificando un archivo .xap en un área segura del sitio.
2. Divida la aplicación en dos o más módulos. El .xap inicial, situados en un área no seguro del sitio, podría realizar el proceso de autenticación. Si se realiza correctamente, ese archivo .xap podría solicitar uno posterior desde un área segura que se puede cargar dinámicamente en la aplicación de Silverlight. I recientemente blogged acerca de cómo se puede hacer este (thejoyofcode.com/How_to_download_and_crack_a_Xap_in_Silverlight.aspx).

Josh Twist es un consultor principal con el equipo de asesoría de desarrollo de aplicaciones Microsoft en el Reino Unido y puede encontrarse escribiendo blogs en thejoyofcode.com.

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Zulfiqar Ahmed, Chris Barker y Simon Ince