How to implement authentication and authorization using RavenDb in an MVC application?

Question

While I'm well used to using the standard ASP.Net membership provider for new MVC web applications, I have been enjoying using RavenDb lately, but I still don't believe that I have enough best practice for implementing authentication user and role authorization.

The code that I replaced with my registration and login methods in AccountController looks like this:

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

I saw the RavenDb membership provider code referenced by many people in similar posts or questions, but there also seem to be a few people who consider this to be higher, and using an inefficient data warehouse API that doesn't need much of that that is provided in it.

So what is the best architecture / design strategy for RavenDb authentication (and not for OAuth, but Forms Authentication) and I bark the correct tree?

Answer 1

I think there are several parts to this problem. First, from the point of view of the MVC project, you really want to use something that will work with AuthorizationAttribute. This does not actually require the use of the MembershipProvider element as such, but rather stuffs the corresponding IPrincipal in HttpContext.Current.User, since these attributes look for authorization.

From an HTTP point of view, using the existing forms authentication infrastructure also makes a ton of sense - it solves most sticky security problems that you really don't have to solve yourself, and it is very flexible in terms of working with what you provide.

From there you will get to the bottom of the question - how do you want to return your authentication system in terms of data. I think this is a very tactical challenge - some applications may make sense just using the MembershipProvider style model. But if I had an application that was very user-oriented, where I stored a lot of user data, I would probably think about moving user storage based on my requirements. If you use an authentication package, you can also look at it to some extent. But I do not think that at the moment there is a strict rule - do what makes sense for your application.

One thing you shouldn't do is use AuthenticationUser as mentioned above - this is for database system users. In terms of SQL Server, this will mean that every user in your application will be a SQL user, and then authenticate with that. Here's how some old intranet products worked, but the world has already passed by.