ASP.NET MVC 5 Authentication Breakdown

In my previous post, "ASP.NET MVC 5 Authentication Breakdown", I broke down all the parts of the new ASP.NET MVC authentication scheme. That's great, but I didn't have a working example that you, a curious developer, could download and play around with. So I set out today to figure out what the bare minimum code needed was. Fiddling around, I was able to get OWIN powered authentication into an ASP.NET MVC app. Follow this guid to get it into your application as well.

No fluff, just the real stuff

TL;DR go to https://github.com/khalidabuhakmeh/SimplestAuthMvc5 to clone the code.

NuGet Packages

You will need the following packages from NuGet in your presumably empty ASP.NET MVC project.

1. Microsoft.AspNet.Identity.Core
2. Microsoft.AspNet.Identity.Owin
3. ASP.NET MVC 5
4. Microsoft.Owin.Host.SystemWeb
5. Microsoft.Owin.Security
6. Microsoft.Owin.Security.Cookies
7. Microsoft.Owin.Security.OAuth
8. Owin

Notice how the majority of them center around Owin.

Start Up Classes

OWIN follows of a convention of needing a class called StartUp in your application. I followed the standard pattern of using a partial class found in the default ASP.NET MVC 5 bloated template.

Here is the main code file:

using Microsoft.Owin;
using Owin;

[assembly: OwinStartup(typeof(SimplestAuth.Startup))]

namespace SimplestAuth
{
    public partial class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            ConfigureAuthentication(app);
        }
    }
}

Followed by the implementation of the ConfigureAuthentication method:

    public partial class Startup
    {
        public void ConfigureAuthentication(IAppBuilder app)
        {
            app.UseCookieAuthentication(new CookieAuthenticationOptions
            {
                AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
                LoginPath = new PathString("/Login")
            });
        }
    }

Web.Config settings

OWIN doesn't use the standard forms authentication that I've grown to love, it implements something completely different. For that reason, I have to remember this snippet of config.

<system.web>
    <authentication mode="None" />
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" />
  </system.web>
  <system.webServer>
    <modules>
      <remove name="FormsAuthenticationModule" />
    </modules>
  </system.webServer>

The FormsAuthenticationModule is removed, and additionally the authentication mode is set to None. Although, I know the site will have authentication; that authentication will be handled by OWIN.

Authentication Controller

Now it's business time! Now we just need a controller to authentication and create the cookie for authentication. We'll also implement log out, because sometimes our users want to leave (not sure why though :P).

Note: I'm using AttributeRouting here. Giving it a try, but I love Restful Routing.

public class AuthenticationController : Controller
    {
        IAuthenticationManager Authentication
        {
            get { return HttpContext.GetOwinContext().Authentication; }
        }

        [GET("login")]
        public ActionResult Show()
        {
            return View();
        }

        [POST("login")]
        [ValidateAntiForgeryToken]
        public ActionResult Login(LoginModel input)
        {
            if (ModelState.IsValid)
            {
                if (input.HasValidUsernameAndPassword)
                {
                    var identity = new ClaimsIdentity(new [] {
                            new Claim(ClaimTypes.Name, input.Username),
                        },
                        DefaultAuthenticationTypes.ApplicationCookie,
                        ClaimTypes.Name, ClaimTypes.Role);

                    // if you want roles, just add as many as you want here (for loop maybe?)
                    identity.AddClaim(new Claim(ClaimTypes.Role, "guest"));
                    // tell OWIN the identity provider, optional
                    // identity.AddClaim(new Claim(IdentityProvider, "Simplest Auth"));

                    Authentication.SignIn(new AuthenticationProperties
                    {
                        IsPersistent = input.RememberMe
                    }, identity);

                    return RedirectToAction("index", "home");
                }
            }

            return View("show", input);
        }

        [GET("logout")]
        public ActionResult Logout()
        {
            Authentication.SignOut(DefaultAuthenticationTypes.ApplicationCookie);
            return RedirectToAction("login");
        }
    }

I'll leave out the implementation of the views, because it is pretty standard Razor syntax. The thing to take note in the code above is the creation of a ClaimsIdentity. All yourcode needs to do is generate this class, and it doesn't matter from where: Database, Active Directory, Web Service, etc. The rest of the code above is really just boilerplate. You'll just need to use the AuthenticationManager from the OWIN context to SignInand SignOut.

Conclusion

There you have it. A basic breakdown of what you need to do to get OWIN authentication in your ASP.NET MVC applications without the craziness that comes standard in the Visual Studio templates. The standard templates in Visual Studio force you to use Entity Framework and has a lot of ceremony for what is essentially a really simple solution. So do yourself a favor and dump that mess and just implement something that makes more sense for you and your team.

Update

A reader ran into a nasty redirect issue in his production environment after deploying. This was a simple IIS Setup issue. If you are experiencing the same issue, please do the following in your IIS environment:

• Disable Windows Authentication Module
• Disable Forms Authentication Module (should have already)
• Enable Anonymous Authentication Module

Having multiple authentication methods on can lead to very strange behaviors. Good luck and I'd love to hear how your projects are going. I also recommend you read one of my later posts on securely storing passwords.