¿Cómo debo hacer la autenticación en un sitio ASP.Net MVC?

Question

Tengo un sitio que tiene un área que requiere autenticación. Ahora mismo uso el atributo de roles en todos los controladores en esa área, y ejecuto una consulta para recuperar esa ID de usuario y toda su configuración.

Parece un código o olor a diseño que estoy recuperando el usuario y la configuración cada vez que se carga un controlador en esa área? No estoy seguro de si debería usar sesiones, o si ASP.Net MVC 2.0 ofrece alguna forma única de manejar esto. Otra preocupación es la seguridad.

En general, realmente no sé qué camino tomar. En cuanto al diseño, me gustaría que el usuario y la configuración se recuperen solo una vez cuando el usuario inicia sesión en el área. En este momento agarro el ID del usuario cada vez que se carga un controlador, y luego, si es necesario, consulto también la configuración de la base de datos cada vez.

Answer 1

Una de las reglas sobre seguridad es que no debe intentar hacerlo usted mismo. Existen muchas dificultades al hacer correctamente un sistema de autenticación sin dejar huecos ni puertas traseras. Por lo tanto, en ese sentido, podría considerar el SqlMembershipProvider que viene con .NET. Se puede usar con MVC y proporciona los medios para obtener roles y el contexto de seguridad actual, es fácil de configurar y configurar y será más seguro que el propio.

Si no está utilizando SQL Server, tiene un par de opciones. Una solución sería usar algo como SQL Server Express o SQL Server Compact Edition para mantener las credenciales. Otra solución sería imitar el esquema de la base de datos SqlMembrershipProvider y luego escribir un proveedor personalizado que se comunique con ese esquema.

La última opción sería escribir una clase MembershipProvider personalizada. Si bien esto sigue siendo el propio, te obliga a entrar en la estructura del MembershipProvider para poder cambiarlo más tarde por uno diferente (por ejemplo, ActiveDirectoryMembershipProvider) y proporciona una interfaz común para interactuar con las credenciales y los inicios de sesión que, por ejemplo, permite un uso fácil del control de inicio de sesión integrado.

Si ya está utilizando un MembershipProvider y está preguntando por el almacenamiento de datos adicionales específicos del usuario, entonces le sugiero al SqlProfileProvider todas las advertencias que mencioné anteriormente sobre el SqlMembershipProvider. el ProfileProvider proporciona una estructura para mantener los datos específicos del usuario con el usuario que está conectado.

Para más información:

• Introduction to Membership
• Implementing a MembershipProvider
• ASP.NET Profile Providers

Answer 2

Puede almacenar un objeto en sesión que contenga toda la información de usuario requerida. Solo deberá agregar una propiedad en los Controladores, Vistas u otras clases base donde desee recuperar la información/perfil del usuario. Esta sería la información de autorización en lugar de cualquier información de autenticación (por ejemplo, autenticación de formularios)

Answer 3

También podría implementar una identidad personalizada. Son muy fáciles de implementar y te permiten almacenar la información de usuario que desees en Identity, que luego se almacena en las cookies que apaga Identity, por lo que no estás accediendo al DB cada vez para obtener esa información.

Solo crea una nueva clase que herede de GenericIdentity y estarás en camino.

Por supuesto, debe tener cuidado con la cantidad de información que coloca allí, ya que está en una cookie, pero generalmente la información relacionada con el usuario en el caso que está tratando aquí no es tan grande.

Utilizamos una identidad personalizada para almacenar algunos bits de información sobre el usuario, y funciona bastante bien.

Answer 4

Usted puede tratar de "Windows Identity Foundation". Lo he estado usando en uno de mis proyectos por un tiempo. Permite la "autenticación basada en notificaciones", lo que básicamente significa que puede designar "reclamos", cadenas de información que describen al usuario cuando inicia sesión.

Una vez iniciada la sesión, las afirmaciones del usuario se pueden leer en el campo HttpContext.Current.User. También puede usar reclamos "Rol" que se integran a la perfección con un esquema de autenticación basado en roles; lo que significa que puede darle al usuario un reclamo de función de "administrador" y luego usar `if (User.IsInRole (" manager ")).

Como una ventaja adicional, WIF hace que sea muy fácil volver a utilizar su pantalla de inicio de sesión en otras aplicaciones.

En general, es muy flexible, pero la documentación es muy pobre. He preguntado y respondido una serie de preguntas sobre "Windows Identity Foundation" en StackOverflow.

Answer 5

Hemos hecho esto bastantes veces en el pasado. Similar a lo que menciona Thomas, lo que generalmente hemos hecho es implementar un nuevo proveedor de Membresía basado en el proveedor Microsoft SQL Memberhsip para hacer esto. Heredamos de la clase base MembershipUser y agregamos cualquier propiedad personalizada que quisiéramos tener en el objeto del usuario. Debe implementar una lectura de base de datos para el proveedor de Membresía en la implementación de GetUser, para que pueda consolidar sus propiedades adicionales que necesita en la lectura de la base de datos.

Si está utilizando el servidor SQL, Microsoft ha lanzado el código 2.0 para él. Puede obtener más información en el blog de Scott Gu.

http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx

Si desea empezar de cero, sino que también tienen buenos recursos en MSDN.

http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx

y

http://msdn.microsoft.com/en-us/library/6tc47t75.aspx

Una vez que haya implementado su proveedor, a continuación, puede añadir el usuario suscrito a la colección de artículos del contexto web actual para obtener acceso a él desde su código . Las propiedades no extendidas de la clase de usuario base base también están disponibles en el hilo Solicitud como normal.

Con el lanzamiento de Microsoft de la versión 2.0 del código fuente, encontramos que nos ayudó a aliviar algunas preocupaciones que existen sobre la reinvención. Otra cosa a considerar para sus implementaciones se basa en su escenario, puede eludir la implementación de parte del código. Un ejemplo de esto sería el código CreateUser si está golpeando un sistema de back-end que ya tiene la información de credencial.

Answer 6

Parece que está relativamente satisfecho con su proceso de autenticación, pero desea explorar otras opciones para la sesión/configuración.

Mi sugerencia tiene que ver con la configuración solamente (roles, preferencias, etc.)

En mi opinión, tener que atravesar toda la pila de tecnología desde la interfaz de usuario al nivel empresarial hasta el nivel de base de datos a DB es a veces un poco exagerado. Para los datos que no es probable que cambien durante una sesión, esto agrega una gran sobrecarga ... Se pueden producir varias transformaciones de datos (DB (Formato relacional) -> ORM -> Servicio web Serialización XML -> Deserialización del nivel web)

Puede considerar un sistema de sesión que no dependa de un sistema RDBMS pesado o en el modelo de caché/sesión de ASP.NET. Hay opciones que son muy efectivas y que se escalan bien.

Puede usar RavenDB por Ayende Rahien (Built for .NET). Su objetivo principal es proporcionar acceso de baja latencia y alto rendimiento a documentos JSON sin esquema.

Con esta solución, configuraría ravenDB en el nivel web para que el acceso a los datos sea muy rápido. La primera vez que autentica y recupera la configuración, almacenaría la información de usuario y configuración en esta sesión DB. Cada vez que carga el controlador después de eso, se puede acceder a los datos de configuración sin tener que volver al RDBMS. Esta base de datos también se puede usar para almacenar en caché otros datos relacionados con la web.

En cuanto a la seguridad, los datos de configuración llegan al nivel web independientemente del método que utilice. Esta solución no sería más o menos segura que las otras opciones (más segura que una cookie no encriptada). Si lo necesitara, podría cifrar los datos de la sesión, pero eso aumentará su sobrecarga nuevamente.

Simplemente otra de las millones de opciones a considerar.

buena suerte,

Háganos saber lo que decida!

Patrick.