ASP.NET Identity & ASP.NET Membership Provider "Mashup"

Question

We have an existing web application that's been built on MVC & SQL Membership provider for user authentication. The application also includes admin management screens for creating/editing users, resetting passwords, activating accounts etc... It's quite a mature system and has been in production for ~2.5 years.

We now have a new requirement to expose some data from the system via API, and we're looking at WebApi as a candidate technology.

One of the issues I'm running into is around the authentication. I'd like to leverage the existing user/role management functionality in our application, to create and manage the API accounts. However since the preferred option for WebAPI is to use ASP.NET Identity (claims/bearer tokens etc...) I'm a bit confused about what the best options would be.

Would it be possible or a bad idea to somehow shoe-horn in the existing membership provider user/password authentication into the web api auth mechs. There's a method in the ApplicationOAuthProvider, that looks like I could manipulate by replacing the line IdentityUser user = await userManager.FindAsync(context.UserName, context.Password); with a call to the MembershipProvider. This seems very cludgy though.

Thought & options would be greatly appreciated.

Answer 1

Not really an answer, just my 0.02 cents.

I think you'll spend as much time shoe-horning MembershipProvider into new Identity, as it would take to properly update to the new Idenitty framework.

I've done upgrade in 2 different systems, both not small (one 200K, another 70K lines of code) with extended number of users. Smaller system took me 7 man-days, larger one 5 days (I knew what I was doing second time -). Both system had extended number of user management code, one of the systems had a way to impersonate another user for admins. Everything worked smoothly and there was no downtime. Users did not notice a difference.
But after upgrade things with user management/authentication were so much easier, you'll get your 5 days spent on upgrade in no time. Think of this as an investment -))

I've looked on source code (in decompiler) of MembershipProvider and a lot of things are static, messy, sealed and just plain unmanageable. I'd say it'll be easier dump it instead of building more legacy code, just to maintain dying library.

In other words, it'll be easier to update everything instead of trying to re-use old stuff.

Answer 2

This could be done by implementing your own UserStore. I think there would be a lot of dragons though. You would have to think through all those other scenarios and reconcile the two: forgot password, email confirmation, login failure counts and timespans, and so on. Basically everything that updates your user data would have to be thought through, and perhaps done doubly in each set of tables. If you could add the columns to your existing membership tables to support the interface of the asp.net identity that may help, but at some point you will end up scrapping most of the data access portion and implementing a full UserStore instead of one you mostly delegate to the original Entity Framework based code.