W jaki sposób uwierzytelnianie i autoryzacja byłyby realizowane za pomocą RavenDb w aplikacji MVC?

Question

Podczas gdy jestem dobrze przyzwyczajony do korzystania ze standardowego dostawcy członkostwa ASP.Net dla nowych aplikacji internetowych MVC, ostatnio używam RavenDb, ale wciąż nie wierzę, że mam pojęcie o najlepszej praktyce do implementacji uwierzytelniania użytkownika i autoryzacji roli.

Kod Wymieniłem moje metody rejestrowania i logowania się w AccountController wygląda następująco:

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

Widziałem kod Provider RavenDb Membership, że wiele osób nie odwołuje się w podobnych stanowisk lub pytania, ale wydaje się też, że jest wielu ludzi, którzy uważają, że jest to przesada i wykorzystują nieefektywny interfejs API dla magazynu danych, który nie potrzebuje większości tego, co jest w nim przewidziane.

Jaka jest najlepsza strategia architektoniczna/projektowa dla uwierzytelniania RavenDb (nie dla OAuth, ale Forms Authentication) i czy szczerzę odpowiednie drzewo?

Answer 1

Myślę, że jest kilka części tego problemu. Po pierwsze, z perspektywy projektu MVC, naprawdę chcesz użyć czegoś, co będzie działać z AuthorizationAttribute. To faktycznie nie wymaga korzystania z MembershipProvider per se, ale raczej wypychania odpowiedniej IPrincipal do HttpContext.Current.User, ponieważ to właśnie atrybuty te patrzą na autoryzację rzeczy.

Z perspektywy HTTP korzystanie z istniejącej infrastruktury uwierzytelniania formularzy ma również sens - rozwiązuje większość problemów związanych z bezpieczeństwem, których naprawdę nie należy rozwiązywać samodzielnie, i jest bardzo elastyczne pod względem pracy z dostarczasz.

Od tego momentu dochodzisz do sedna pytania - w jaki sposób chcesz poprzeć system uwierzytelniania z perspektywy danych. Myślę, że jest to bardzo taktyczne połączenie - niektóre aplikacje mogą mieć sens, aby użyć modelu stylu MembershipProvider. Ale gdybym miał aplikację, która byłaby bardzo skoncentrowana na użytkowniku, w której przechowywałbym wiele danych użytkownika, prawdopodobnie rozważałbym przewrócenie niestandardowego sklepu użytkownika w oparciu o moje wymagania. Jeśli korzystasz z pakietu Authentication, możesz do tego w pewnym stopniu doszukać się. Ale nie sądzę, że w tym momencie istnieje twarda i szybka zasada - rób to, co ma sens w przypadku Twojej aplikacji.

Jedną z rzeczy, których nie powinieneś robić, jest użycie AuthenticationUser jak wyżej - jest to przeznaczone dla użytkowników systemu baz danych. W terminach programu SQL Server byłoby tak, jak każdy użytkownik w aplikacji byłby użytkownikiem SQL, a następnie uwierzytelniałby się w ten sposób. W taki sposób działały stare produkty intranetowe, ale świat już minął.