Seguridad de LightSwitch

Protección del acceso a las aplicaciones LightSwitch

Valerie Andersen

Matt Evans
Sheel Shah
Michael Simons

Seamos realistas: implementar la seguridad en las aplicaciones puede ser una tarea intimidante. Afortunadamente Visual Studio LightSwitch facilita la administración del acceso basado en permisos de las aplicaciones en la línea de negocio (LOB), lo que permite crear aplicaciones con una lógica de control de acceso que cumple con las necesidades precisas de la empresa.

Las aplicaciones LightSwitch están divididas en tres niveles lógicos: presentación, lógica y almacenamiento de datos; para garantizar un nivel de acceso adecuado hay que examinar el acceso a los recursos de cada uno de estos niveles. LightSwitch permite crear la lógica de control de acceso en el nivel correcto de la aplicación. Por lo demás, LightSwitch aprovecha los fundamentos del control de acceso de las tecnologías subyacentes y permite configurar los aspectos más comunes del acceso de control de acceso mediante IIS y ASP.NET.

En este artículo se muestra cómo funciona el control de acceso en las aplicaciones LightSwitch. Primero se describirán las características de LightSwitch que permiten el acceso de control en las arquitecturas de tres niveles. A continuación se revisará brevemente la implementación, en la medida en que tiene relación con el control de acceso y se mostrarán otras formas de controlar aún más el acceso con las tecnologías que respaldan LightSwitch. Finalmente, se examinará el acceso de control al implementar la aplicación en un entorno de Windows Azure.

Conceptos básicos sobre el control de acceso

El control de acceso en las aplicaciones LightSwitch tiene dos aspectos. El primero es la autenticación, o cómo la aplicación comprueba si un usuario realmente es quien dice ser. El segundo es la autorización, que define lo que el usuario tiene permiso de hacer o ver en la aplicación.

Autenticación

El proceso de autenticación determina si un usuario es quien dice ser. El primer nivel de control de acceso en LightSwitch exige que los usuarios se identifiquen en la aplicación. Los modos de autenticación posibles son autenticación por Windows y autenticación por Formularios. Estas opciones se pueden configurar en la pestaña de Control de acceso de las propiedades de la aplicación, como se muestra en la Figura 1.

Figura 1 Definición de los permisos en el Diseñador de aplicaciones

Se recomienda usar la autenticación por Windows cuando todos los usuarios se encuentran en un dominio de Windows y se puede confiar en que la persona que inicia sesión en el equipo es la misma que usa la aplicación. La autenticación por Windows no exige un nuevo inicio de sesión, y la aplicación no requiere de contraseñas ni tiene que administrarlas ni almacenarlas fuera de Windows. La autenticación por Windows es la alternativa más segura, pero generalmente solo es una alternativa práctica cuando la aplicación se ejecuta en el entorno de una red privada corporativa con un dominio.

Con la segunda opción, la autenticación por Formularios, el usuario debe escribir el nombre de usuario y la contraseña al abrir la aplicación. En LightSwitch estos valores se comparan y revisan con una base de datos en forma predeterminada. La autenticación por Formularios funciona perfectamente en el caso de los clientes que se ejecutan a través de Internet y los que no se encuentran en un dominio de Windows.

En el caso de la autenticación por Formularios hay que agregar los usuarios en el sistema antes de que puedan acceder a la aplicación. La autenticación por Windows también puede funcionar del mismo modo, pero hay una opción que se puede establecer durante el diseño que permite que todos los usuarios de Windows que pueden iniciar sesión en el dominio tengan acceso a la aplicación de manera predeterminada. Todas las partes de la aplicación que requieran de permisos específicos no estarán accesibles para los usuarios de Windows que no se hayan agregado en forma explícita.

La autenticación permite identificar a los usuarios que pueden o no usar la aplicación, y en algunas situaciones esto es todo lo que hace falta para cumplir con los requisitos de control de acceso. Una vez que el usuario está autenticado, se le confía el acceso completo a todos los datos. En este caso, la implementación del control de acceso está completa y ya no se requiere de permisos ni de código adicionales. Lo único que queda por hacer es examinar las opciones de IIS que se analizan en la sección Reflexiones sobre la implementación del control de acceso para proteger las aplicaciones en el servidor de hospedaje.

Pero muchas aplicaciones requieren de un control más fino del comportamiento de los usuarios una vez que se fueron autenticados. En estas situaciones se necesitan las autorizaciones.

Autorización

LightSwitch ofrece un sistema de autorización basado en permisos para desarrollar reglas de negocio, tal como se muestra en la Figura 2.  

Figura 2 Implementación de la autorización en LightSwitch

Los permisos se definen en el diseñador de aplicaciones (ver Figura 1). Luego se puede escribir código para comprobar que el usuario tenga los permisos requeridos. Como los métodos de control de acceso se pueden implementar en las entidades, consultas o en las pantallas, resulta muy fácil escribir la lógica para determinar si el usuario actual puede ver o manipular datos puntuales en una pantalla en particular.

LightSwitch tiene un permiso integrado llamado Administración de seguridad, y todos los usuarios que reciben este permiso se convierten en administradores de la seguridad. El permiso de Administración de seguridad permite que el usuario que haya iniciado sesión tenga acceso a las pantallas de Administración de seguridad en la aplicación cliente en ejecución, las cuales se mostrarán automáticamente a los usuarios que han recibido este privilegio. El administrador de seguridad crea los roles necesarios para la aplicación y asigna los permisos deseados a cada rol, tal como se puede observar en la Figura 3. Luego se crean los usuarios y se asignan al rol adecuado, tal como se puede observar en la Figura 4.

Figura 3 Creación de los roles en tiempo de ejecución

Figura 4 Asignación de usuarios a los roles en tiempo de ejecución

La primera vez que la aplicación se implementa, hay que agregar un administrador de seguridad al rol de Administración de seguridad para habilitar el acceso inicial a la aplicación. El proceso de implementación ofrece la ayuda necesaria para la configuración de este usuario predeterminado. Una vez que se está ejecutando la aplicación implementada, el sistema no permite eliminar el último usuario con el permiso de administrador de seguridad, para garantizar que en todo momento exista al menos un administrador de seguridad.

Pero no hace falta implementar la aplicación para comprobar que el comportamiento de los permisos esté correcto. Cuando una aplicación LightSwitch se ejecuta en el modo de depuración, el sistema de roles y de autenticación se ejecuta en un modo especial en el que el entorno de desarrollo automáticamente intenta autenticar un usuario de prueba especial. En el diseñador de LightSwitch en la columna “Concedido para depuración”, se pueden conceder o denegar los permisos que tiene este usuario de prueba. La aplicación luego se ejecuta en modo de depuración con los permisos seleccionados, lo que permite probar la lógica de permisos codificada. De este modo, se puede validar en forma rápida que las comprobaciones de los permisos sean precisos, sin que haga falta configurar varios usuarios y roles de prueba.

Importancia del lugar donde se realiza el control de acceso de los recursos de la aplicación

Veamos ahora qué es lo que hay que proteger y cómo hacerlo. Muchas aplicaciones tienen algunos datos que son confidenciales y hay que ocultar, otros que solo tienen que ser protegidos contra manipulación y otros que probablemente se pueden acceder sin ningún tipo de protección. El primer lugar en el que hay que pensar acerca de la protección es probablemente el nivel lógico. Cuando los desarrolladores controlan correctamente los datos en el nivel lógico, entonces el nivel de la presentación frecuentemente reacciona de manera correcta y en forma automática. Por ejemplo, si un usuario no tiene permiso para borrar los datos del tipo Employee, entonces la cuadrícula con los datos del tipo Employee tiene deshabilitado el botón para borrar. Así de poderoso y fácil resulta crear las aplicaciones con LightSwitch.

Al implementar el control de acceso en el nivel de los datos, la aplicación se vuelve más segura y los desarrolladores aprovechen la inteligencia integrada. Si los datos solo se protegen en el nivel de presentación, los datos quedan expuestos en el nivel lógico. Un usuario malintencionado autenticado podría eludir el nivel de presentación y acceder al servicio directamente para leer o manipular los datos. Esto se relaciona con la arquitectura de tres niveles de las aplicaciones LightSwitch, y de hecho es común a todas las aplicaciones de tres niveles. El nivel de presentación es el responsable de presentar los datos de manera adecuada; pero no es la única forma para que un usuario autenticado acceda los datos cuando el nivel lógico no tiene implementados los controles de acceso adecuados.

Protección de los datos en el nivel lógico

El nivel lógico incluye dos grupos principales de componentes donde se revisan los permisos: las entidades y las consultas.

Entidades Las entidades conforman el mecanismo general para acceder a los datos de la aplicación y trabajar con ellos. Las entidades permiten cuatro acciones principales: leer, insertar, actualizar y eliminar. LightSwitch proporciona un punto de enlace para comprobar los permisos del usuario cada vez que se realiza una acción y también proporciona una API sencilla para comprobar si el usuario actual tiene los permisos precisos definidos en la aplicación. En el siguiente código se muestra un ejemplo de la comprobación de los permisos y los diferentes métodos puerta que proporciona la API para que los desarrolladores puedan controlar los permisos:

partial void Employee_CanUpdate(ref bool result)
{
  result = Application.Current.User.HasPermission(Permissions.EmployeeUpdate);
}
 
partial void Employee_CanInsert...
 
partial void Employee_CanRead...
 
partial void Employee_CanDelete...
 
partial void SaveChanges_CanExecute...

Cabe mencionar algunas cosas. Primero, todos estos métodos, con la excepción de SaveChanges_CanExecute, están implementados en el conjunto de entidades en su totalidad y no en las instancias individuales de las entidades. Por lo tanto, no se pueden realizar comprobaciones en los valores de una instancia de una entidad en particular. El método SaveChanges_CanExecute controla el acceso a los cambios en todo el origen de datos y por lo tanto no puede contener lógica propia de una entidad ni del conjunto de entidades. Segundo, si el método Employee_CanRead devuelve falso, entonces no se llamarán los métodos Employee_CanUpdate y Employee_CanDelete, ya que éstos también serían falsos de manera implícita. Los usuarios que no cuentan con el permiso para leer una entidad tampoco tienen permiso para actualizar ni eliminarla.

El conjunto de métodos “Can” constituye la forma básica para realizar una seguridad poco detallada. Permite implementar políticas básicas de control de acceso a los datos. Pero tiene algunas limitaciones. Cuando se necesita un control más fino para la lectura de los datos, entonces se puede implementar un control de acceso en las consultas. Para controlar la escritura de los datos en un nivel más granular, hay que hacerlo en la canalización de guardado.

Consultas Las consultas también se protegen en el nivel lógico. Cada consulta tiene un método para controlar el acceso. LightSwitch genera tres consultas en forma automática por cada entidad existente: una consulta All que devuelve todas las instancias de la entidad, más unas consultas Single y SingleOrDefault para devolver una instancia por clave. Cada una de estas consultas integradas tiene un método CanExecute que permite implementar un control de acceso:

partial void Employees_All_CanExecute(ref bool result)
{
  result = Application.Current.User.HasPermission(Permissions.QueryEmployees);
}
 
partial void Employees_Single_CanExecute...
partial void Employees_SingleOrDefault_CanExecute...

Es importante tener en cuenta que es posible componer las consultas de LightSwitch, es decir, se pueden crear consultas nuevas basadas en consultas existentes. Cuando se aplica una lógica de control de acceso a las consultas, los requerimientos de los permisos de la consulta inicial sirven de entrada a las consultas compuestas por esta consulta. Las consultas Single y SingleOrDefault están compuestas por las consulta All y por lo tanto, al proteger la consulta All también se protegen estas consultas, siempre y cuando no se especifique ningún permiso adicional para las consultas derivadas. Pero también se pueden especificar los permisos en la consulta derivada; estos son menos restrictivos que los permisos que se establecen en la consulta de base. Además, el método CanRead del conjunto de entidades se aplica antes del método CanExecute en todas las consultas de este tipo.

En la Figura 5 se muestra un ejemplo de la composición de consultas: si la consulta NorthAmericaEmployees se crea en la entidad Employee, esta consulta se compone en la consulta integrada Employee_All. Por lo tanto, cualquier lógica de control de acceso aplicada mediante Employee_All_CanExecute también se aplica a la consulta NorthAmericaEmployee, ya que ésta se basa en la consulta Employee_All, siempre y cuando no se haya escrito ningún código para la consulta entregada. Por ejemplo, para permitir que solo determinados usuarios puedan acceder a los datos de la entidad NorthAmericanEmployees se podrían abrir o restringir puntualmente los permisos de esta consulta con el método NorthAmericaEmployees_CanExecute.

Figura 5 Composición de consultas en la entidad Employee

Control de acceso en diferentes relaciones

Al trabajar con consultas en diferentes relaciones es importante entender que los permisos se controlan en las entidades en forma de relaciones y se atraviesan en las todas entidades relacionadas. Este es otro motivo por el cual resulta importante tener definidos correctamente los permisos en las entidades. Para proteger los datos del acceso de lectura mediante relaciones, el método CanRead de la entidad tiene que tener el nivel de permiso correcto. Veamos por ejemplo nuevamente la tabla Employee y los datos de compensación relacionados que se muestran en el modelo de la Figura 6.

Figura 6 Modelo de una aplicación de recursos humanos

Al atravesar la relación entre Employee y Compensation mediante una consulta, los permisos en las acciones leídas por la entidad se evalúan a medida que se atraviesa la relación, en vez de los permisos en el método Compensation_All_CanExecute. Al atravesar las entidades los permisos tienen que estar establecidos correctamente en el método CanRead de la entidad Compensation para lograr el nivel de permisos correcto. Hay que tener presente que es posible usar consultas para deducir los datos cuando las entidades no están protegidas. En el caso de una consulta que devuelve los empleados mejor pagados, por ejemplo, como la que se muestra en la Figura 7, la entidad de compensación a la que se accede para devolver los datos de Employee tiene que estar protegida correctamente para que solo los usuarios con los permisos necesarios puedan tener acceso a estos datos por medio de la consulta.

Figura 7 Definición de una consulta para devolver los empleados mejor pagados

Una experiencia personalizada para la presentación

Una vez que los datos están protegidos en el nivel lógico, es hora de diseñar la experiencia del usuario en el nivel de la presentación. Cuando no se quiere que un usuario tenga acceso a una pantalla en particular se puede desactivar la pantalla con el método <ScreenName>_CanRun para la aplicación. Cuando un usuario no tiene acceso a una pantalla determinada, entonces ésta no aparece en su menú de navegación. También es posible restringir los comandos que aparecen en la pantalla con el método <CommandName>_CanExecute.

Además de estos, existen muchos otros métodos en las pantallas y las entidades que permiten ocultar, mostrar y controlar el estado editable de los controles específicos en una pantalla, como por ejemplo <EntityProperty>_IsReadOnly, <ScreenControl>.IsEnabled, <ScreenControl>.IsReadOnly y <ScreenControl>.IsVisible. Si bien el control de acceso no es la función principal de estos métodos, son bastante útiles para entregar la experiencia de usuario deseada. En algunos casos puede ser preferible ocultar los datos que no pueden manipular los usuarios; otras veces será preferible mostrar controles de solo lectura; y algunas veces habrá que guiar a los usuarios para que escriban los datos en forma correcta y entregar errores que tengan sentido cuando las cosas salen mal. El nivel de presentación de LightSwitch entrega toda esta flexibilidad.

Hay que entender correctamente que proporcionar lógica en la pantalla que oculte, muestre o controle el estado editable de los datos no protege los datos del acceso de los usuarios, solo controla la forma en que se muestran los datos. Existe la posibilidad que un usuario malintencionado ataque directamente el servicio del nivel lógico para ver o manipular los datos si no están protegidos adecuadamente. Por esta razón es fundamental implementar el control de acceso de manera adecuada en todos los niveles de la aplicación.

Protección de los datos en el nivel de almacenamiento

El nivel de almacenamiento es donde se almacenan los datos en una base de datos. Para controlar el acceso a los datos en el nivel de almacenamiento se puede proporcionar un inicio de sesión a la base de datos con el mínimo necesario de privilegios en la base de datos. La aplicación usa este inicio de sesión para conectarse a la base de datos y realizar todas las operaciones necesarias. En una implementación de tres niveles toda la conectividad a los datos se realiza mediante el nivel intermedio, y los usuarios finales jamás tienen acceso directo a los datos o las cadenas de conexión. Al implementar una aplicación LightSwitch hay que especificar la cadena de conexión que usará la aplicación para acceder a los datos, como se puede observar en la Figura 8. Cuando la aplicación no tiene un inicio de sesión único para la base de datos, LightSwitch guiará al administrador de la aplicación para que cree uno. Se recomienda estrictamente que el usuario de la base de datos se emplee únicamente para la aplicación específica y que solo reciba el acceso a los datos usados por la aplicación.

Figura 8 Especificación de las credenciales de la conexión a la base de datos para ejecutar la aplicación durante la implementación

Es importante mencionar que también existe la posibilidad de usar una implementación de dos capas para implementar una aplicación LightSwitch segura. En la implementación de dos capas el nivel de lógica y el nivel de presentación se ejecutan en el equipo de escritorio del usuario. Como esta configuración permite que el usuario acceda al archivo web.config donde se almacena la cadena de conexión para la base de datos, no ofrece la separación de los niveles de presentación y lógica necesaria para que la aplicación sea segura. Con la cadena de conexión el usuario puede obtener un acceso directo a la base de datos y eludir toda la lógica de control de acceso del nivel intermedio. En este caso lo mejor es usar la autenticación por Windows en el nivel intermedio y la base de datos. De lo contrario, se necesita una implementación en tres capas para proteger la aplicación de manera adecuada.

Aspectos de la implementación del control de acceso

Al implementar una aplicación LightSwitch por primera vez, hay que crear un usuario administrativo para LightSwitch. Inicialmente, este es el único usuario que tiene permisos administrativos. Luego se usa este usuario para configurar los roles y los usuarios dentro de la aplicación cliente, tal como se describió previamente. Observe que este usuario será un administrador de la aplicación LightSwitch, pero no tiene por qué ser un administrador de Windows. También existe una utilidad para la línea de comandos que permite crear un nuevo usuario administrativo fuera del proceso de implementación. La utilidad Microsoft.LightSwitch.SecurityAdmin.exe se encuentra en el directorio de instalación de LightSwitch.

Uso de las características de control de acceso de IIS

Ahora que ya examinamos las funcionalidades de control de acceso propias de LightSwitch, revisemos brevemente algunas formas adicionales que tiene el administrador de una aplicación para proteger manualmente las aplicaciones de LightSwitch con las tecnologías de apoyo.

LightSwitch y SSL al igual que los exploradores y servidores web, los clientes y servidores LightSwitch se comunican por medio del protocolo HTTP. Éste especifica que los datos se deben enviar como texto sin cifrar, por lo que la conexión está expuesta a que una persona malintencionada en la red observe los datos que intercambian los clientes y servidores. Para proteger las comunicaciones contra estos individuos hay que emplear el protocolo HTTPS que oculta los datos del HTTP normal en un túnel cifrado.

Las aplicaciones LightSwitch se pueden implementar de modo tal que los clientes se comuniquen con el servidor mediante HTTPS. Esto no solo protege los datos de negocio confidenciales que se intercambian entre el cliente y el servidor, sino que también los nombres de usuario y contraseñas, al usar la autenticación por Formularios. El procedimiento recomendado es implementar un sitio HTTPS cuando se emplea la autenticación por Formularios en conjunto con IIS o Windows Azure. De lo contrario, un atacante podría apropiarse del token de autenticación y suplantar al usuario que inició sesión. En el caso de la autenticación por Windows no es posible que un atacante recupere las contraseñas de los usuarios o los suplante, ni si quiera cuando se usa HTTP en vez de HTTPS. Pero independientemente del modo de autenticación, los datos de negocio transmitidos entre el cliente y el servidor están expuestos a una interceptación, a menos que se emplee HTTPS.

SSL y certificados Los servidores web que se comunican por HTTPS se valen de un certificado del servidor que debe estar instalado. Este certificado cumple dos funciones. Primero, el certificado demuestra que el servidor al cual se está conectando el cliente es realmente el servidor correcto y que no ha sido suplantado ni alterado. Segundo, el certificado del certificado contiene la información de la clave secreta que se emplea para cifrar todos los datos que se envían al cliente.

Para que un explorador web pueda confiar en la identidad de un servidor que no ha contactado anteriormente, el certificado del servidor tiene que haber sido firmado criptográficamente por una entidad de certificación (CA) de confianza. Los certificados se pueden comprar en diferentes proveedores tales como verisign.com, entrust.net, instantssl.com o geocerts.com. Como la mayoría de los proveedores cobra por generar o firmar los certificados de los servidores, en los entornos de desarrollo se acostumbra usar un certificado autogenerado y sin firmar (y que por lo tanto por lo tanto no es de confianza).

Cuando se conecta una aplicación web LightSwitch mediante HTTPS y el servidor usa un certificado que no es de confianza, el comportamiento depende del explorador web que se use. Como mínimo, el explorador informará el problema del certificado y preguntará si debe continuar. Para las aplicaciones web LightSwitch esto debiera funcionar correctamente.

Sin embargo, en el caso de una aplicación LightSwitch de escritorio que está hospedada por IIS y a la que se accede mediante HTTPS, el servidor IIS tiene que usar un certificado de confianza. Silverlight no aceptará ninguna aplicación que provenga de un certificado que no sea de confianza. Un certificado que no sea de confianza provocará que la aplicación aparentemente se instale correctamente, pero al iniciarse se producirá un error. Para remediar este problema hay que forzar que el explorador web confíe en el certificado del servidor, para lo cual hay que preinstalarlo en el almacén de los certificados del cliente o reemplazar el certificado del servidor con uno que haya sido firmado por una CA de confianza. Observe que habrá que tomar estas medidas correctivas antes de acceder a la aplicación por primera vez desde un cliente dado; de lo contrario, el cliente interpretará la situación como que el certificado cambió o ha sido alterado.

IIS El servidor IIS no requiere de ninguna configuración específica para LightSwitchpara poder hospedar las aplicaciones LightSwitch con SSL. Los administradores del servidor deben habilitar HTTPS en el servidor web y seleccionar un certificado en la forma normal.

De hecho, es posible hospedar la misma aplicación LightSwitch con HTTP y HTTPS, y en algunas situaciones esto es una alternativa útil. Pero recuerde que, tal como mencionamos anteriormente, cualquier cliente que no se conecte mediante HTTP no será capaz de proteger las contraseñas ni la información confidencial de la empresa.

De manera predeterminada, en las versiones más recientes de IIS, el sitio web predeterminado escucha las conexiones entrantes de HTTP y HTTPS. El administrador del servidor puede forzar que una aplicación LightSwitch implementada en este tipo servidor requiera el protocolo HTTPS y redirigir cualquier conexión HTTP entrante al extremo HTTPS. Esta configuración se ubica en el archivo web.config de la aplicación LightSwitch.

Configuración del grupo de aplicaciones Cuando se publica en IIS hay que evaluar la posibilidad de ejecutar la aplicación en su propio grupo de aplicaciones. Los grupos de aplicaciones permiten aislar los procesos de trabajo (por lo tanto, cuando una aplicación web deja de responder no se ven afectadas las otras aplicaciones del servidor), pero también permiten ejecutar la aplicación bajo diferentes identidades. Por lo tanto, se puede crear un grupo de aplicaciones que hospede una aplicación web o un conjunto de servicios que se ejecutan bajo una identidad de Windows determinada, y permitir el acceso únicamente a aquellos recursos que la identidad necesita para ejecutar la aplicación. En el caso de las aplicaciones LightSwitch este recurso adicional es la base de datos. De manera predeterminada, el asistente de implementación publica la aplicación en el grupo de aplicaciones ASP.NET 4 que se ejecuta bajo la identidad de la cuenta de la máquina. Sin embargo, esta identidad no tiene acceso a la base de datos de la aplicación, y por lo tanto al ejecutar la aplicación se genera un error similar a “Error de inicio de sesión del usuario ‘IIS APPPOOL\ASP.NET v4.0.’”

Aquí tenemos varias alternativas. Al usar el nombre de usuario y contraseña para SQL Server en la cadena de conexión, la aplicación probablemente funcionará sin más cambios (siempre cuando el usuario cuente con el acceso necesario a la base de datos). Pero cuando se prefiere la autenticación por Windows para la conexión a la base de datos, se requiere de un grupo de procesos independiente para poder configurarlo para que se ejecute bajo una cuenta de usuario con privilegios mínimos. Esta cuenta también debe tener el acceso requerido a la base de datos de la aplicación.

Cuando se usa la autenticación por Windows en IIS 7, hay que tener en cuenta otro valor de configuración adicional. Al usar una identidad de usuario personalizada como la identidad del grupo de aplicaciones, hay que usar el proveedor de Windows NT LAN Manager (NTLM) (no Kerberos) o habilitar la compatibilidad con la autenticación de Kerberos. Otra alternativa es usar la identidad del Servicio de red como la identidad del grupo de aplicaciones y agregar este acceso de cuenta a la base de datos.

Protección de las aplicaciones LightSwitch en Azure

Todas las aplicaciones LightSwitch hospedadas en Windows Azure se pueden acceder en forma pública. Por lo tanto, estas aplicaciones tienen un conjunto único de requisitos para el control de acceso.

Cifrado SSL De manera predeterminada, LightSwitch emplea un extremo HTTPS cuando publica una aplicación en Windows Azure. Así se garantiza que toda la información confidencial sobre la empresa se comunique en forma cifrada a través de Internet. Durante la publicación, LightSwitch ofrece la opción de crear un certificado SSL autofirmado para la aplicación. Si bien esto resulta muy útil para probar la aplicación en Windows, se recomienda enfáticamente el uso de un certificado licenciado de un proveedor externo, tal como se describió previamente. Como las aplicaciones de escritorio no funcionan mediante SSL con un certificado que no sea de confianza, se puede desactivar el cifrado SSL con fines de depuración (mediante el portal de Windows Azure) una vez que la aplicación se implementó correctamente, para lo cual se debe establecer el valor de la implementación de Microsoft.LightSwitch.RequireEncryption en falso.

Después de probar la aplicación con el certificado SSL autofirmado, se puede actualizar el certificado SSL, sin tener que volver a publicar la aplicación mediante el portal de Windows Azure. Para volver a cargar un nuevo certificado SSL para la aplicación hospedada, hay que cambiar el valor de SSLCertificate a la huella digital del certificado nuevo y volver a activar el cifrado.

Autenticación de la aplicación Para prevenir el acceso no autorizado a las aplicaciones LightSwitch hospedadas en Windows Azure, se recomienda la autenticación por Formularios. Para esto, no hace falta realizar ninguna configuración adicional del servidor después de publicar la aplicación. Pero si la aplicación requiere de una autenticación por Windows, habrá que unir la aplicación LightSwitch publicada al dominio. Esto requiere de Windows Azure Connect. Para encontrar orientación sobre cómo habilitar Windows Azure Connect, consulte bit.ly/qx0Z6n.

Seguridad de la base de datos SQL Azure Las aplicaciones LightSwitch normalmente emplean SQL Azure como la base de datos interna. Esta base de datos es necesaria cuando se crean tablas en LightSwitch o se emplea la autenticación. SQL Azure emplea un firewall y credenciales de usuario para la protección contra un acceso no autorizado.

Para permitir que las aplicaciones LightSwitch hospedadas en Windows Azure se conecten a la base de datos, hay que establecer en verdadero la regla del firewall “Permitir que otros servicios de Windows Azure obtengan acceso a este servidor”. LightSwitch también exige que se agregue una regla de firewall para la dirección IP de la máquina que publica la aplicación. Se recomienda eliminar esta regla una vez que se publicó la aplicación. Así se prevendrá que una máquina externa pueda acceder a la base de datos.

En resumen

LightSwitch permite que los desarrolladores creen aplicaciones empresariales en forma sencilla y productiva, y lo mismo se cumple para la implementación de las características de control de acceso. Los desarrolladores pueden restringir el acceso a las aplicaciones en forma rápida y sencilla mediante la autenticación. Cuando se requiere de un control más fino, las características de autorización proporcionan una forma poderosa para definir los permisos y proteger los recursos en los niveles lógicos y de datos de la aplicación para controlar en forma eficaz el acceso de los usuarios. Se pueden aprovechar algunas características comúnmente usadas de IIS y Windows Azure para desarrollar una solución de control de acceso completa. La innovación, sin embargo siempre está en las manos del desarrollador. Puede encontrar más información del equipo de desarrollo de LightSwitch en blogs.msdn.com/b/lightswitch.

 

Valerie Andersen trabaja como directora de programas de Microsoft en Visual Studio LightSwitch. Su meta es crear características para LightSwitch que permitan que los desarrolladores del mundo real puedan crear rápida y cómodamente aplicaciones seguras de calidad para cumplir con las necesidades de los clientes alrededor del mundo.

Matt Evans trabaja como evaluador de software en LightSwitch. Su meta es que las aplicaciones LightSwitch sean todo lo seguras que tienen que ser.

Sheel Shah trabaja como director de programas de Microsoft en LightSwitch. Su tarea dentro del equipo se centra en el diseño de la compatibilidad con Windows Azure, implementación y características del cliente de LightSwitch.

Michael Simons trabaja como desarrollador jefe de Microsoft en LightSwitch. Su función dentro del equipo consiste en desarrollar características de datos y seguridad.

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Dan Leeaphon, John Rivard, Dan Seefeldt y Matt Thalman