Customization Options With ASP.NET Identity

Thursday, January 9, 2014

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. angry identity bird

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:

1. For New Applications

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.

2. For Existing Applications

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.

3. Using Identity 2.0 (And Integer Keys)

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.

Account confirmation
Password Reset
Security Token Provider
Better Katana Integration
And more….

4. Ripping Things Apart

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.

You don’t need to take a dependency on the Entity Framework in the assembly where you define a user
In fact, you don’t need the Entity Framework at all
The only constraint on a user is to implement IUser, which requires Id and UserName properties

The next post in this series will look at building a custom user store both with a relational and non-relational database.