How to use Identity membership with existing database (n-tier)

Question

I've been reading various other questions about using asp.net-identity but I don't see anything concrete with regards to using it with an existing database when the project is developed in tiers. For argument's sake, say the following is true:

• Solution
  • WebUI
  • Services
    • UserService
  • Data
    • MyDbContext
  • Core
    • User

How can I specify User (from the Core project) to be the IUserStore for the new identity provider? Am I missing something, or does this all assume that the website and the membership database always reside in the same project(or there are strict references to the Microsoft.AspNet.Identity.* libraries wherever the models reside)?

Setting up a DbContext at the WebUI layer just for authentication (and tie it in to the "MyDbContext" with a service) seems hacky. Am i missing something, or was the team just planning on this being only used in simple applications?

And feedback would be appreciated.

More Information

if it's worth mentioning:

• This would be a completely new solution; I do not have old/existing aspnet_* or webpages_* tables to worry about. I'm trying to take various other custom solutions and tie them in to one solid solution, so I'm open to a lot of options. However, I would like to keep things broken out by layer (if at all possible).

Lamarre

Is your existing DB having Membership tables from ASP.NET Membership framework? – Alcmene

For existing Membership Db, you shall take steps to migrate it to new ASP.NET Identity framework. asp.net/identity/overview/migrations/… – Alcmene

No (I assume you're referring to the AspNet* tables), but that isn't much different than SimpleMembership I assume (other than a more dynamic tie to which model is the user, the role, etc?)? – Lamarre

And so it's known, this would be a virgin application; No need to convert old/antiquated code, old tables, etc. I am familiar with and have worked with SimpleMembership in some of my later projects, but we're retiring those solutions (so no need to worry about bringing that over either). – Lamarre

If you don't want to take a dependency on the Entity Framework implementation from Core, you pretty much have to implement IUserStore and the other interfaces consumed by UserManager yourself, which isn't too difficult, but it is unfortunate. – Borchers

@odetocode So I'm noticing. At this point I'm considering implementing my own (ran through the code and nothing too elaborate in there). Just have to get familiar with the claims – Lamarre

@BradChristie I'm totally with you on this one. I don't get all this fuzz about getting all these extra tables automatically created that seemed quite generic. I personally don't use Roles and never really found a need to get extra generic tables like paths, applications, schemaversions (from the Membership) just to be able to register/login a user on my system. BTW, did you identify the right way to write you own inherited implementation? – Duplessismornay

@EagertoLearn: Totally hacked it and kept the authentication in the WebUI and the Data context in its layer; I use the same database, but modified the authentication to use a usr schema (so they can both sit atop the same database). Not the best solution (and would probably lean towards ILMerge as the next step) but needed to just get it completed for now. – Lamarre

I'm having this exact same issue. Does anyone else have a better solution? I dont want to have another dbContext in my Web project. Another solution i can thing of is to scrap the ASP.NET Identity and just use the Owin IAuthenticationManager - khalidabuhakmeh.com/asp-net-mvc-5-authentication-breakdown – Barram

@BradChristie Thanks for this help. Have you used UserManager from MS.AspNet.Identity.Core? Have smth similar in my project (please check at #31025359) And I was thinking to use UserManager and implement my own IUserStore and other persistence. How do you think? – Weighin

@Artem: Indeed I have, but unfortunately, due to the way its written, decoupling the model from the actions remain difficult. – Lamarre

Answer 1

Asp.net Identity Framework is set of components helping application to work with User Identity. Core framework blocks are in Microsoft.AspNet.Identity.Core assembly. The second Microsoft.AspNet.Identity.EntityFramework is the data persistence implementation for the Core framework.

Now for the n-tier application, you can define your AppUser model in any project/assembly. You need to inherit it from the Microsoft.AspNet.Identity.EntityFramework.IdentityUser. So based on your approach, you need to reference particular assembly.

Same is for the MyDbContext. You must inherit from the currently only available Persistence Microsoft.AspNet.Identity.EntityFramework.IdentityDbContext<TUser>. Your MyDbContext can be in other project/assembly. You need to refer to your AppUser assembly too in this project/assembly.

Alcmene

Before down-voting read the complete question and its comments and then read answer. The answer given here fits the written context to my understanding. – Alcmene

Not sure I understand why it is required to inherit from IdentityUser here. As we can implement our own IUserStore which would use IUser implementation. That is in case we go without Identity.EntityFramework classes. Could you explain the necessity to inherit here? Thanks! – Weighin

@Artem, you are right. If you are creating your own implementation, its not required to inherit from IdentityUser which is part of Microsoft.AspNet.Identity.EntityFramework. But if you are just customizing for the application using Microsoft.AspNet.Identity.EntityFramework, you must inherit from IdentityUser. – Alcmene