Identity and membership systems are difficult to implement because there is such a wide variety of business needs and technology requirements for these systems. Out of the box solutions for identity management will never make everyone happy and are guaranteed to make somebody angry.
Here are a few thoughts, pointers, and links revolving around customization options with the new ASP.NET Identity features.
But first, previous posts in this series:
The sweet spot for ASP.NET Identity is a greenfield application with minimal architectural constraints. If you are comfortable taking a dependency on the Entity Framework and aren’t trying to apply domain driven design to a complex problem space, the Identity framework is a quick approach to storing usernames, passwords, and logins.
By deriving from IdentityUser you can store custom profile properties per user. By deriving from IdentityDbContext you can add relationships between members and other data in a system.
Migrating existing applications to use the Identify framework is a bit trickier. You’ll need to provide some custom mapping for EF to work with an exiting schema, and also manage hashed passwords in a way that the Identity password hasher understands (which is extensible through an IPasswordHasher typed property on the UserManager class. Recently, a few articles appeared to help with this scenario:
The Identity framework doesn’t yet include all of the features of the previous membership frameworks, so you should perform a gap analysis before heading in this direction.
Based on feedback from the first release of the Identity framework, there is already a prerelease of Identity 2.0. Most notable in this release is the addition of an IUser<TKey> type, where TKey is the type of the primary key / identifier for a user. IUser<TKey> is useful for anyone who doesn’t like the default string type for a primary key. More information is available in the blog post Announcing preview of Microsoft.AspNet.Identity 2.0.0-alpha1, where you can also see the following improvements.
There are a number of good reasons to use the Identity framework’s UserManager class while implementing your own user store persistence logic.
For starters, implementing your own persistence logic in a scenario where you just need users with passwords, but not roles, claims, or 3rd party logins, is relatively straightforward. The UserManager can work with a class only implementing IUserStore and IUserPasswordStore, which require a total of 8 CRUD type methods. Following this path has a few benefits.
The next post in this series will look at building a custom user store both with a relational and non-relational database.
Brock Allen’s analysis: The good, the bad and the ugly of ASP.NET Identity
Khalid Abuhakmeh’s analysis: ASP.NET MVC 5 Authentication Breakdown and ASP.NET MVC 5 Authentication Breakdown : Part Deux
A database project template from Konstantin Tarkus to work with Identity in a DB first approach: ASP.NET Identity Database
A customization article by John Atten: Code-First Migration and Extending Identity Accounts in ASP.NET MVC 5 and Visual Studio 2013
Brock Allen’s Membership Reboot
Thinktecture’s IdentityServer 2