In a running application, once the user’s password has been validated (against the persisted password) then the user is logged into the application (typically) with some sort of cookie based mechanism like ASP.NET’s Forms authentication, WIF’s Session Authentication Module, or now in Visual Studio 2013 OWIN cookie middleware. Keep in mind that (as always) the provider model is simply about the storage and management of account related data. In this sense, this new identity framework is a success and quells one of the long standing complaints about the previous membership systems. With this design it should be very straightforward and obvious for a developer using this framework what data is stored and how it is stored. The ApplicationDbContext class is primary there for you to control connection strings to indicate the database to actually use.
There’s even less to code or customize on the ApplicationDbContext because its base already defined the DbSet for the user accounts (in its base class). It requires an EF DbContext, which is provided by another class generated in your project called ApplicationDbContext.
See this post for an example.įor the class that implements IUserStore, there is a class from the ASP.NET Identity EF assembly called UserStore. Given EF’s support for POCOs, this extra data on the user account class will simply be mapped into the database with little effort on your part.
Any custom data you’d want stored on your user accounts would be added to this class. When you choose “Individual User Accounts” in the new ASP.NET templates in Visual Studio 2013 you will get an IUser implementation in a class called ApplicationUser. There are default implementations of these interfaces that use Entity Framework 6. This extra data would then be stored by your implementation of the IUserStore. If you want more data associated with your user you can add it on your custom user class that implements this interface. This also makes it easier for developers to customize the user account data. The idea is that you then implement these interfaces and this puts you in control of how the account data is actually stored. Public interface IUserStore : IDisposable where TUser : IUser The way they’ve done this is by defining the account related data behind an interface, IUser and the storage operations behind another interface IUserStore. username, password, etc.) from the code that implements the security (e.g., password hashing, password validation, etc.). With this release, they’ve actually achieved a separation of the storage of the identity information (e.g. One of the major complaints with the previous identity management frameworks was that it was either too cumbersome (with Membership) or too subtle (with SimpleMembership) to customize the storage. TLDR Click here to get to the ugly conclusion. Let’s take a look at the good and the bad aspects of this new framework. ASP.NET Identity is yet another identity management framework from Microsoft (recall that we also had two prior frameworks from Microsoft: Membership and SimpleMembership). NET 4.5.1 we have a new framework called ASP.NET Identity. Ok, here we go again… and if you don’t know what I’m talking about, then see this post.