none
Autentificación y Autorización RRS feed

  • Pregunta

  • Saludos a todos

    Estoy desarrollando una aplicación web con Asp.Net MVC 4 (con view engine razor), que es bastante grande. Estamos utilizando las tablas de usuarios, roles, menus parametros, etc de un sistema que esta ya en producción pero con WinForms.

    Empezamos la parte del login, me entraron muchas dudas y espero que me puedan guiar para resolverlas.

    Hay muchos ejemplos en internet que la autentificación y autorización la realizan con MemberShip Provider hay tres opciones si me introduzco a este tema:

    1.- Realizar la implementación de MemberShip Provider, esto lo debo descartar por que ya tengo mis tablas creadas.

    2.- Personalizar (customize) la implementación de MemberShip Provider, lo que leí hay bastante información de no hacerlo por que ocupamos funciones que no las utilizaremos y por lo que se indica en este post: Usar o no usar el modelo de Membership Provider en ASP.NET MVC?

    1. Para poder testear el Membership Provider deben hacerse paranoias varias (encapsularlo en una interfaz) para "evitar" el uso de esas llamadas estáticas que son imposibles de simular en tests unitarios. 
    2. El Membership Provider está más que hinchado. Crearse un custom membership provider implica meter cuatro mil "throw NotImplementedException()" en todos aquellos métodos que TU aplicación no soporta... y ver donde colocas aquellos que TU aplicación necesita pero que no están incorporados en el Membership Provider base. 
    3. La creación del Membership Provider la gestiona el propio runtime de ASP.NET, por lo que inyectarle dependencias tiene sus dificultades (aunque es posible). 

    De acuerdo a lo que leí me hace inclinar a la no utilización de esta opción. Creen que es buena la personalización de MemberShipProvider, lo ven conveniente? para el caso que les planteo en las primeras lineas de este post. 

    3.- Es la que mas me agrada pero no encontré mucha información y haber si me pueden colaborar que debo tomar en cuenta para la implementación de desarrollar nuestros propios métodos de Autentificación y Autorización. Aquí ya tengo los metodos de autentificación (del sistema que esta con winform) cuando haga el login el usuario pero al hacer esto quiero guardar en una session todo mi objeto Usuario y Rol para poder realizar la autorización a ciertas páginas del sistema e investigando  leí que no es una buena practica la utilización de sesiones , que se puede utilizar Cache, Velocity (App Fabric) y Cookies cual recomiendan para guardar los datos del objeto Usuario y Rol, algun ejemplo? de tal forma que pueda preguntar cuando ingrese a ciertos sitios si tiene permiso a esa página?

    A la espera de sus sugerencias y guias

    Saludos

    Ricardo


    • Editado ricardo_jal sábado, 24 de noviembre de 2012 13:43 error redacción
    sábado, 24 de noviembre de 2012 12:11

Respuestas

  • Veamos... el tema es complejo.

    Mi opinión es que el Membership Provider tal y como está planteado no aporta nada a asp.net mvc, a no ser que quieras usar la aplicación de configuración de asp.net para usuarios y roles. O bien que uses algún componente de terceros que asuma que el Membership existe y está configurado. O que quieras aprovechar el AccountController que te genera VS (cosa que no te recomiendo :p). En caso contrario el uso de Membership te aportará más dolor de cabeza que otra cosa, a no ser que uses el esquema por defecto y una base de datos tipo Sql Server, en cuyo caso no tienes que hacer nada.

    Eso sí, si estás en MVC4, para liar un poco más el tema ha aparecido "otro" (entre comillas) sistema de Membership, llamado SimpleMembership que es bueno... más simple que el actual. Usar SimpleMembership es una opción más razonable, siempre y cuando estés con MVC4 (supongo que puede usarse con MVC3 pero no lo he probado la verdad). Hace nada (ayer :p) escribí en mi blog un post sobre SimpleMembership: http://geeks.ms/blogs/etomas/archive/2012/11/25/asp-net-simplemembership-una-vuelta-de-tuerca-m-225-s.aspx

    SimpleMembership tiene varias ventajas sobre el Membership clásico, y es el que usa VS2102 si usas el template MVC4 - Intranet Application (si usas el MVC4 - Basic Application usará el Membership clásico). Las más importantes son que es más sencillo de configurar, más fácil de usar (a través de un "wrapper" que es la clase WebSecurity) y que se adapta a tu esquema de BBDD. Lo negativo que tan solo funciona con cualquier producto de la familia de Sql Server (Sql Server, Sql Server Compact, Sql Server Express y LocalDb).

    Referente a tu punto 3. Autenticar un usuario (al menos en lo que se refiere al Membership) lo que significa es ir a un proveedor de credenciales (puede ser Active Directory, un LDAP o lo más normal una BBDD con una tabla "Usuarios") y comprobar las credenciales que ha pasado el usuario. Eso, si usamos una BBDD, es código estándard de acceso a datos. Puedes usar ADO.NET, EF o lo que prefieras por ahí. Luego una vez compruebas que las credenciales son correctas debes autorizar todas las peticiones sucesivas de dicho usuario (aquí usuario se refiere a ventana de navegador). Eso se hace, por norma general, estableciendo una cookie, pero en el caso de ASP.NET esto se hace llamando a FormsAuthentication.SetAuthCookie. Este método ya establece la cookie y el propio sistema de autenticación de ASP.NET hace el resto. Esta cookie es leída automáticamente por ASP.NET y sus datos (que por norma general es tan solo el login del usuario) son colocados dentro del objeto User del HttpContext. Además si la cookie existe, la propiedad IsAuthenticated del objeto Request se pone a true. Aunque por defecto la cookie contiene tan solo el login del usuario, usando este login y accediendo a la BBDD (o donde sea) puedes obtener el resto de datos. Si quieres guardar datos adicionales a la cookie de autorización puedes hacerlo (mira este post de mi blog que cuento como: http://geeks.ms/blogs/etomas/archive/2010/12/16/asp-net-obtener-el-id-del-usuario-actual.aspx). Por supuesto puedes establecer los mecanismos de cache que creas necesarios para evitar que cada vez que quieras saber la ciudad del usuario debas ir a la BBDD p.ej. (o lo que aplique en tu caso).

    > leí que no es una buena practica la utilización de sesiones

    El uso de sesiones no es ni bueno ni malo. Pero hay que tener presente todo lo que implica. La sesión es un recurso caro y debe usarse con precaución. Para seguir con el autobombo que me estoy pegando en esta respuesta puedes leerte este post de mi blog sobre la sesión: http://geeks.ms/blogs/etomas/archive/2010/06/30/asp-net-mvc-q-amp-a-c-243-mo-usar-la-sesi-243-n.aspx

    Y recuerda que para preguntar si alguien tiene acceso a una página (este concepto es muy de webforms en MVC diriamos "acceso a una acción del controlador"), debes usar siempre los mecanismos provistos por la clase User (p.ej. User.IsInRole) o bien la clase Request (Request.IsAuthenticated). Si usas MVC tienes el atributo [Authorize] si prefieres hacerlo declarativamente.

    Para cualquier otra cosa... ya sabes! ;-)


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis

    • Marcado como respuesta ricardo_jal martes, 27 de noviembre de 2012 15:42
    lunes, 26 de noviembre de 2012 16:09