ASP.NET Identity – the new way of handling authentication and authorization in asp.net

For a while now my project build reported that FormsAuthentication is deprecated so I knew I’ll need to look into the latest thing at some point. That point came – and my feelings are mixed.

Don’t get me wrong – I think that the ASP.NET Identity is WAY better than what was there earlier, but I do hold a grudge that not all use cases are now supported. The good news is that it’s really easy to make it work the way you want, so despite that Microsoft doesn’t want to support certain use cases, my project can.

The problem is with the place I store user data. The default would be the db, but for reasons that are beyond this blog post, the project I’m handling uses the web.config to do that. In FormsAuthentication this was handled by the “authentication” tag in system.web section in the web.config file. As weird as that sounds, there are a few cases where using this is justified (I hope).

Now that ASP.NET Identity is out there’s no way to do that out of the box, but as I mentioned before – it’s easy to extend it so that this is still possible. Here’s a link on how to do that so enough ranting and let’s see what ASP.NET Identity is all about.

There’s a good introduction to that subject here. I don’t want to repeat what’s there so, I’ll just write my thoughts.

ASP.NET Identity was introduced to handle authentication through social sites: Facebook, Twitter, Google, Windows Live, Stack overflow, OpenID and the likes of that. THIS IS GOOD.

I don’t know if I emphasized that enough, so let me give it another go – THIS IS REALLY REALLY REAAAALLLY GOOD.

The pain of handling authentication has been following web developers for a long long time. It’s been following web users even longer. Each portal, separate login, separate password (which we all know is just not happening). With OpenID came hope, but problems as well. Now the web is at a stage where the majority or users have a facebook/twitter/google/microsoft account, and they use it too, so if the big players can handle authentication – they should – there’s even a name for that – single sign-on.

The problem was, to get this to work on your site. It was possible to pull of, but as a developer, you had to struggle. Now that ASP.NET Identity is here, all you need to do is install the right package.

As this is relatively new, not all providers are there yet, but the big players are, along with the option to store credentials in your own db – so you’ve got the majority covered and the minority needs to ‘stick with you’ – good enough.

So what’s the thing about?

The big picture

There are a few packages that are available in nuget:

• Microsoft.AspNet.Identity.Core – package containing core components
• Microsoft.AspNet.Identity.OWIN – package with the OWIN plugin – this generates the authentication cookie
• Microsoft.AspNet.Identity.EntityFramework – this package allows to store identity data in the db using entiity framework (code first)
• Microsoft.Owin.Security.* – that includes Google, Facebook, Twitter, MicrosoftAccount – these support the authentication through mentioned services.

The powerpoint slide

The new identity system supports things like claims based authentication, roles, is unit testable and allows to store the identity credentials in any place (some out of the box, others need custom implementations).

The basics

To use the identity system in an asp.net app, you need to utilize a few thigs:

Microsoft.Identity.Owin.Security.IAuthenticationManager

The implementation for this interface can be obtained like this:

   1: HttpContext.GetOwinContext().Authentication

This object can be used to call SignIn() and SignOut() – usage should be clear, but call that on what? Well, you’ll need an identity and to have that you need a UserManager to create one.

Microsoft.AspNet.Identity.UserManager<T> where T: IUser

This class allows to create, delete and find users  as well as to create identities. An identity is created for a user and can be used to make authorization and authentication decisions.

If the manager finds the user who tries to log in, the authentication process can continue. It class has a constructor dependency on IUserStore<T>.

This is a utility class which means that you can live without it – just need more boilerplate code. There’s also a RoleManager<> which has the same functionality, except for roles.

Note that this is the only class that doesn’t implement a specific interface – probably because, as I mentioned, it’s a utility class, but it is kind of a shame that there’s no IUserManager – I bet that sooner or later, someone will find a necessity for that.

On a side(ish) note – if your login process utilizes a custom hashing mechanism or does some unusual things – this is the class that you’ll need to extend. Thankfully, it has a lot of extension points.

Microsoft.AspNet.Identity.IUserStore<T> where T : IUser

This interface allows to access the list of registered users.

Microsoft.AspNet.Identity.IUser

This interface is required by Microsoft.AspNet.Identity.IUserStore. This should be implemented by your user class – meaning – if you want to store more information then the user name and user id you should create a POCO class that implements this interface.

Microsoft.AspNet.Identity.IUserPasswordStore<>, IUserRoleStore<> and the likes

There are a few more interfaces available. The necessity for them depends on the usage scenario. But most likely – you won’t need to worry about them – either because you won’t use them, or because they’ve already been implemented for you in a “common provider package” so e.g. Microsoft.Owin.Security.Google.

Wraping up

This should be enough to get started. For more info go here or just grab the newest mvc5 project template and create a new project with “Individual User Accounts” authentication – all the ‘standard’ code will be there for you. Enjoy.

Cheers