Come implementare l'autenticazione e l'autorizzazione utilizzando RavenDb in un'app MVC?

Question

Mentre sono abituato a utilizzare il provider di appartenenza ASP.Net standard per le nuove applicazioni Web MVC, ultimamente ho iniziato a utilizzare RavenDb, ma non credo ancora di avere una conoscenza delle migliori pratiche per l'implementazione dell'autenticazione utente e dell'autorizzazione dei ruoli.

Il codice ho sostituito i miei metodi registro e di accesso con l'AccountController si presenta come la seguente:

[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... 

Ho visto il codice di provider RavenDB appartenenza che un certo numero di persone hanno fatto riferimento in post o simili domande, ma sembra anche che ci sia un numero di persone che considerano questo aspetto eccessivo e sfruttano un'API inefficiente per un archivio dati che non ha bisogno della maggior parte di ciò che viene fornito al suo interno.

Quindi qual è la migliore strategia di architettura/progettazione per l'autenticazione RavenDb (non per OAuth, ma l'autenticazione basata su form) e sto abbaiando nell'albero giusto?

Answer 1

Penso che ci siano alcune parti di questo problema. In primo luogo, dal punto di vista del progetto MVC, vuoi davvero utilizzare qualcosa che funzioni con AuthorizationAttribute. Questo in realtà non richiede l'utilizzo di un MembershipProvider di per sé, ma piuttosto l'inserimento di un IPrincipal appropriato in HttpContext.Current.User poiché questo è ciò che quegli attributi guardano per autorizzare le cose.

Da un punto di vista HTTP, l'utilizzo dell'infrastruttura di autenticazione dei moduli esistenti ha anche un senso - risolve la maggior parte dei problemi di sicurezza che non dovresti davvero risolvere da solo ed è molto flessibile in termini di funzionamento Tu provvedi.

Da lì si ottiene il succo della domanda: come si desidera eseguire il backup del sistema di autenticazione dal punto di vista dei dati. Penso che sia una chiamata molto tattica: alcune app potrebbero avere senso usare solo un modello di stile MembershipProvider. Ma se avessi un'app che è stata molto user-centrica in cui stavo conservando molti dati utente, probabilmente prenderemo in considerazione la possibilità di creare un negozio utente personalizzato in base alle mie esigenze. Se si utilizza il pacchetto di autenticazione, si potrebbe anche approfondire questo argomento. Ma non credo che a questo punto esista una regola ferrea: fai ciò che ha senso per la tua app.

Una cosa che non dovresti fare è usare l'AuthenticationUser come sopra - che è pensato per gli utenti del sistema di database. In termini di SQL Server sarebbe come rendere ogni utente della tua app un utente SQL e quindi autenticarsi in base a quello. Qual è il modo in cui alcuni vecchi prodotti intranet funzionavano, ma ora il mondo è passato oltre.