2

I am currrently using ASP .Net MVC 5 Identity framework to manage user authentication in my simple MVC 5 application. My Database contains 5 Identity related tables: 

dbo.AspNetUsers
dbo.AspNetRoles
dbo.AspNetUserRoles
dbo.AspNetUserClaims
dbo.AspNetUserLogins

What I want to achieve is, basically, to remove AspNetRoles, AspNetUserRoles(which is just a relations table) and AspNetUserClaims. And leave only:

dbo.AspNetUsers 
dbo.AspNetUserLogins

because I'm currently working on OAuth2.0 based user login system. I do not need roles. All i want to know about user is he logged in or not. There are no managers, administrators or other user roles in my application. How can I remove them from my application and still be able to use Identity framework for user authorization/authentication and OAuth? And is it possible in the first place?

Dmytro
  • 16,668
  • 27
  • 80
  • 130

2 Answers2

4

I'm not aware of a way to do this.

What you're looking to do is remove some integral pieces from Identity. Since it's ultimately Entity Framework generating the tables, you might be able to achieve what you're looking to do by rolling your own models based on the Identity code, snipping out the pieces you don't need- but I think you're going to spend a lot of time and effort running down dead ends trying to get that to work properly.

I think I'd just leave it be and chalk it up to future-proofing you application.

joelmdev
  • 11,083
  • 10
  • 65
  • 89
1

Yes you can do this without too much difficulty. The real reason is why? These things are already created and you go through additional work to remove them. If you don't need them, don't use them.

If you're a bit of a purist then these are the steps necessary to change that...

If you take a look at the Microsoft.AspNet.Identity namespace you'll see another namespace called Microsoft.AspNet.Identity.EntityFramework. This namespace is essentially the "default way of doing things". Remove and replace all references to this namespace with your own implementations of things.

This would include...

  1. public class IdentityDbContext<TUser>
  2. public class IdentityUser
  3. public class UserStore<TUser>
  4. Others?

So you would want to create your own equivalents to these, the key driver being the UserStore which is the interface between Identity to your own database.

I wrote an answer on some more details of this using the DB first approach, but this would also apply to Code-first (with some modifications)

Community
  • 1
  • 1
jamesSampica
  • 12,230
  • 3
  • 63
  • 85