How would authentication and authorization be implemented using RavenDb in an MVC app?

Question

While I'm well used to using the standard ASP.Net Membership Provider for new MVC web applications, I've been getting a kick out of using RavenDb lately but I still don't believe I have a grasp on the best practice for implementing user authentication and role authorisation.

The code I have replaced my Register and Logon methods with in the AccountController looks like the following:

[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've seen the RavenDb Membership Provider code that a number of people have referenced in similar posts or questions, but there also seems to be a number of people who consider this to be over the top and leveraging an inefficient API for a data store that doesn't need most of what's provided within it.

So what is the best architectural / design strategy for RavenDb authentication (not for OAuth, but Forms Authentication) and am I barking up the right tree?

Answer 1

I think there are a few parts to this problem. First, from the MVC project's perspective, you really want to use something that will work with the AuthorizationAttribute. This actually does not require using a MembershipProvider per se, but rather stuffing an appropriate IPrincipal into HttpContext.Current.User as that is what those attributes look at to authorize things.

From a HTTP perspective, taking advantage of the existing forms authentication infrastructure also makes a ton of sense -- it solves most of the sticky security issues you really should not solve yourself and it is very flexible in terms of working with what you provide.

From there you get to the gist of the question -- how you want to back your authentication system from a data perspective. I think that is a very tactical call -- some apps it might make sense to just use a MembershipProvider style model. But if I had an app that was very user centric where I was storing lots of user data I would probably consider rolling a custom user store based around my requirements. If you are using the Authentication bundle you could glom onto that to some extent as well. But I don't think there is a hard and fast rule at this point -- do what makes sense for your app.

One thing you should not do is use the AuthenticationUser like above -- that is meant for database system users. In SQL Server terms that would be like making every user in your app a SQL user and then authenticating against that. Which is how some old intranet products used to work but the world has moved past that now.