在现有的Web应用程序中实现ASP.NET Identity

Question

Having read lots of articles and making lots of false starts I need some advise on adding Microsoft ASP.NET Identity to my existing ASP.NET Web Forms application. There are so many subtle differences between my existing application and typical samples out there that I don't know how to get off the ground. Here are some points about my existing application:

1. It is a ASP.NET Web Forms application (.NET Framework 4.6) that has evolved over about 4-5 years
2. It uses SQL Server database though Entity Framework (not Code First but Database First). The database pre-dates the web application and is based on 10 year old designs. It does however have good table relationships etc.
3. My database's schema for Users and Roles are not structured as per "ASP.NET Identity / EntityFramework". It has a [User] table with ID int PK , no username (as such), Password, First Name, Surname, Email and some other properties. It also has a Roles table (4-5 entries) and a UserRoles table that provides many-many relationships. There is no "claims" as such other than properties on the User table.
4. Existing login is based on entering a user id (primary key) and password which is then checked against the user table and on successful login (stored proc), details are then stored in Session - something that in itself isn't quite right!
5. Although using Entity Framework, the Connection String is formed at runtime based on a template connection string in web.config (basically, the database name and server instance name is populated dynamically)

So, here are some the barriers, issues, questions I've come up with. Any advise on any of the questions below would be most appreciated:

1. Should I use as "User.Username" when my web application doesn't have one? Should I use Email Address or UserID? Email address unfortunately isn't unique across the existing [User] data set. Should I use a string version of my (int) UserID?
2. Should I allow ASP.NET Identity to set up its own code first tables into my own database and then add a mapping to my legacy [User] table?
3. How can I inject a "resolver" to provide a (dynamically generated) connection string to the existing ASP.NET Identity Data Stored/Data Access Layer?
4. How much of the Store classes am I likely needing to replace?
5. I've read that NOT using an ORM/EntityFramework can provide very inefficient data access. Does this mean that if implementing my own Storage classes, I can't simply use some of my existing Stored Procedures?
6. My Web Forms application isn't making use of any async code. Is this going to cause me problems with the ASP.NET Identity framework? I've heard that async works best if implemented right through the call stack.
7. Do I need to somehow disable the existing Forms Based Authentication? Are they two going to clash over writing to HttpContext.User for example?

My Schema

CREATE TABLE [dbo].[User](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [OrganisationID] [int] NOT NULL,
    [SaltHashPassword] [nvarchar](128) NOT NULL,
    [FirstName] [nvarchar](64) NOT NULL,
    [Surname] [nvarchar](64) NOT NULL,
    [Email] [nvarchar](128) NULL,
    --...
 CONSTRAINT [PK_User] PRIMARY KEY NONCLUSTERED ([ID] ASC)
) ON [PRIMARY]

CREATE TABLE [dbo].[Roles](
    [Role] [varchar](8) NOT NULL,
    [Name] [varchar](32) NOT NULL,
    [Description] [varchar](1000) NOT NULL,
    [OrderNo] [tinyint] NOT NULL,
 CONSTRAINT [PK_Roles] PRIMARY KEY CLUSTERED ([Role] ASC)--...
 CONSTRAINT [IX_Roles] UNIQUE NONCLUSTERED ([Role] ASC)--...
) ON [PRIMARY]

CREATE TABLE [dbo].[UserRole](
    [UserID] [int] NOT NULL,
    [Role] [varchar](8) NOT NULL,
 CONSTRAINT [PK_UserRole] PRIMARY KEY CLUSTERED ([UserID] ASC,[Role] ASC)
) ON [PRIMARY]

Answer 1

That's a lot of questions here. I think a good starting point is this migration article: Migrating an Existing Website from SQL Membership to ASP.NET Identity

It will probably help you answer most of your questions here, especially 1, 3 and 4.

Answer to Question 2: As ASP.NET Membership and ASP.NET Identity are two different things, I would suggest a full migration, meaning that once you created the new tables for Identity, you map your foreign keys to the new tables and get rid of ASP.NET Membership tables.

Answer to Question 5: I think it depends how you want to set up ASP.NET Identity. In the project I am currently working on, we decided not to use Entity Framework at all, but this makes everything more complex as you have to get very deep knowledge of what happens, when, how, why... So if you are looking for easy implementation, use EF it makes life much more easy and you will find plenty of code samples on Internet.

Answer to Question 6: If you don't use async, it won't cause issues. The only downside is that you won't benefit from it...

Answer to Question 7: Microsoft does not recommend having multiple authentication systems activated. In the project I am currently working on, we managed to have both Identity and Azure AD authentication working together, but we had to develop our own middlewares and it was not that easy. In our web.config, we have:

<system.web>
    ...
    <authentication mode="None" />
    ...
</system.web>