How to remove the role-related tables from ASP.NET Identity Core 2.0

Question

With the advice read-elsewhere that Roles are a subset of Claims, I am looking at a clean way to ask the EF Core implementation in ASP.NET Identity not to create role-relate

Answer 1

This has always been possible in ASP.NET Identity, but has become easier over time, as conventions have moved away from Roles and towards Rights, Actions, Claims, Predicates, and other more reusable and maintainable semantics. I've been using Identity for years in my ASP.NET projects with my pre-existing DB schemas (which have no role tables). I admit, it's quite difficult to understand how to do this due to the cumbersome complexity of ASP.NET Identity, as well as the fast-paced open-source code changes occurring in ASP.NET coupled with the complete lack of human-informed documentation in the API reference (which is entirely boilerplate machine-generated).

Prior to ASP.NET Core, you could do this by overriding UserManager and UserStore implementations. By stubbing out the Role requests with no-ops, or overriding the RoleAttribute implementation with a more useful and developer-safe one (probably not based on magic strings!), the absence of the Role tables goes unnoticed. Even using the default implementations, if you never used default Role attribute implementations or asked Role questions, the tables could be removed without consequence. None of the default ASP.NET scaffolding depends on roles.

In original ASP.NET Core Identity 1.0/1.1 versions, you did this by implementing UserStore without the optional IUserRoleStore interface. Information on that can be found in the main ASP.NET Core Identity documentation.

As of ASP.NET Core 2.0 (per your main question), you could do this more easily by deriving your context from IdentityUserContext instead of IdentityDbContext, as per the example below. This no longer required custom implementations in 2.0 due to the new UserOnlyStore. The call to AddIdentity in Startup.cs also needed to be replaced with AddIdentityCore. AddIdentityCore requires a few extra lines of code if you depend on other standard Authentication features, as by default it does not initialize Cookies or TokenProviders. (As noted below, in 2.1, changes to the boilerplate Startup are no longer required.)

It's quite simple to remove roles in ASP.NET Core 2.1/2.2 (current as of this writing). Here's an example using a new project to demonstrate:

1. Create a new project to demonstrate identity, selecting:

   1. ASP.NET Core Web Application project type
   2. Web Application (either type, e.g. MVC)
   3. Change Authentication
   4. Individual User Accounts
   5. Store user accounts in-app

2. Remove Roles from the newly scaffolded Identity project

   1. edit Data\ApplicationDbContext.cs, elevating the context base class above roles
      • from: ApplicationDbContext : IdentityDbContext
      • to: ApplicationDbContext : IdentityUserContext<IdentityUser>
   2. note that IdentityUserContext requires an IdentityUser generic
   3. due to new Identity code in ASP.NET Core 2.1, that's all that's required

3. Note the IdentityUserContext lacks Role, so custom key types only require 2 arguments

   1. in ApplicationDbContext.cs: IdentityUserContext<IdentityUser<int>, int>
   2. in Startup.cs, AddDefaultIdentity<IdentityUser<int>>() is specified as before
   3. The model provided to the _LoginPartial.cshtml is also specified as before. more details on changing Identity models
   4. if you've changed identity key type, the default EF Migration process fails
      1. EF generates non-functional migrations if you've changed keys
      2. simply deleting Data\Migrations works in test, with these caveats:
         • the scaffolded project included indices that are not default
         • if you've already run the project, you'll need to delete the DB

4. Update/build the database schema to reflect the above. In the Package Manager Console:

   1. Add-Migration RemoveIdentitySchemaRoles
   2. Update-Database

5. Run the app

Answer 2

You can't, and it's very likely Identity would cease to function if you did. Like it or not, Identity utilizes roles. You can choose not to take advantage of this functionality, but it's there nevertheless.

That said, in some sense, every authentication artifact is a "claim". However, claims are abstract concepts, whereas something like a role has a concrete implementation. If you need authorization filters, roles are what you should use. You could use claims, but then you just have to reimplement the concept of a role, anyways. Don't reinvent the wheel.