¿Cómo se implementaría la autenticación y la autorización con RavenDb en una aplicación MVC?

Question

Si bien estoy acostumbrado a utilizar el proveedor de membresía estándar de ASP.Net para las nuevas aplicaciones web de MVC, últimamente me ha gustado el uso de RavenDb, pero sigo sin creer que conozca las mejores prácticas. para implementar autenticación de usuario y autorización de función.

El código he sustituido mis Registro e inicio de sesión con métodos en el AccountController tiene el siguiente aspecto:

[HttpPost] 
public ActionResult Register(RegisterModel model) 
{ 
    if (ModelState.IsValid) 
    { 
    using (IDocumentSession Session = DataDocumentStore.Instance.OpenSession()) 
    { 
     Session.Store(new AuthenticationUser 
     { 
      Name = Email, 
      Id = String.Format("Raven/Users/{0}", Name), 
      AllowedDatabases = new[] { "*" } 
     }.SetPassword(Password)); 
     Session.SaveChanges(); 
     FormsAuthentication.SetAuthCookie(model.UserName, createPersistentCookie: false); 
     // ...etc. etc. 


    [HttpPost] 
    public JsonResult JsonLogOn(LogOnModel model, string returnUrl) 
    { 
     if (ModelState.IsValid) 
     { 
      using (IDocumentSession Session = DataDocumentStore.Instance.OpenSession()) 
      { 
       book Ok = Session.Load<AuthenticationUser>(String.Format("Raven/Users/{0}", Username)).ValidatePassword(Password); 
       FormsAuthentication.SetAuthCookie(model.UserName, model.RememberMe); 
       // etc... 

que he visto el código de proveedor RavenDb membresía que un número de personas que han referenciado en puestos similares o preguntas, pero también parece haber una cantidad de personas que consideran que esto es exagerado y aprovechan una API ineficiente para un almacén de datos que no necesita la mayor parte de lo que se proporciona en él.

Entonces, ¿cuál es la mejor estrategia de arquitectura/diseño para la autenticación de RavenDb (no para OAuth, pero Autenticación de formularios) y estoy ladrando en el árbol correcto?

Answer 1

Creo que hay algunas partes de este problema. En primer lugar, desde la perspectiva del proyecto MVC, realmente desea usar algo que funcione con AuthorizationAttribute. En realidad, esto no requiere el uso de un MembershipProvider per se, sino más bien rellenar un IPrincipal apropiado en HttpContext.Current.User, ya que eso es lo que los atributos miran para autorizar cosas.

Desde una perspectiva HTTP, aprovechar la infraestructura de autenticación de formularios existente también tiene mucho sentido: resuelve la mayoría de los problemas de seguridad que realmente no debería resolver y es muy flexible en términos de trabajar con tu provees.

A partir de ahí se llega a la esencia de la pregunta: cómo desea respaldar su sistema de autenticación desde una perspectiva de datos. Creo que es una llamada muy táctica: algunas aplicaciones podría tener sentido simplemente usar un modelo de estilo MembershipProvider. Pero si tuviera una aplicación muy centrada en el usuario donde almacenaba muchos datos de usuario, probablemente consideraría rodar una tienda de usuario personalizada en función de mis requisitos. Si está utilizando el paquete de Autenticación, también podría centrarse en eso. Pero no creo que haya una regla dura en este punto: haz lo que tenga sentido para tu aplicación.

Una cosa que no debes hacer es usar el AuthenticationUser como se indica arriba, esto es para usuarios de sistemas de bases de datos. En términos de SQL Server, sería como hacer que cada usuario en su aplicación sea un usuario de SQL y luego autenticarse contra eso. Así es como algunos viejos productos de intranet solían funcionar, pero el mundo ya pasó de eso.