ASP.NET 5 Identity MongoDB Implementation
As with everything, ASP.NET Identity will have a new version with ASP.NET 5 which is going to be version 3.0.0. There are some changes on the interfaces but it’s not as drastic as others. By default, it provides Entity Framework implementation which I assume going to be compatible with any data storage system that can plug into Entity Framework (which is good). However, you need to provide a custom implementation if you want to support a data storage system which doesn’t support Entity Framework. MongoDB is one of them and I gave it shot to implement ASP.NET Identity MongoDB store. The result was really good:
Library is available on NuGet as Dnx.Identity.MongoDB package and it supports beta8 runtime release. For now, it’s part of a sample project I am working on but it will probably make it into its own repository soon. I also have a sample here which is the fork of the original Identity sample. You can look at this commit to see what I had to do to make it support my custom provider which is not that bad, if you ignore the dependency injection dance I had to make. That’s because my implementation of ASP.NET Identity library doesn’t support IRoleStore. Don’t worry, you will not need this as you already have IUserClaimStore and also, there is an open issue to change the dependency injection hook a bit so that the IRoleStore would be optional.
Here are a few more details about this ASP.NET 5 Identity MongoDB implementation:
- Currently, there is no documentation.
- MongoUserStore is thread safe. You can register this as a singleton.
- At the moment, there is no logging and nice exception handling for the implementation.
- The implementation only supports dnx452 or above and it doesn’t support corefx as MongoDB .NET Client has no support for that.
- The library doesn’t support SetUserNameAsync as the user name is also the Id of the user. So, you cannot change the Id.
- The implementation requires you to pass an implementation of IMongoDatabase through the constructor and it persists data into a collection which is named "users". There is going to be a way to change the name of the collection soon in upcoming releases.
- E-mail uniqueness is ensured through a unique MongoDB index. However, this will not function properly if you shard the users collection.
- The implementation doesn’t persist changes unless you call one of the UpdateAsync, CreateAsync or DeleteAsync methods (which is what UserManager does).
Give it a try and you can file issues here for now and send pull requests. Enjoy :)