Переход с проверки подлинности ASP.NET членства в ASP.NET Core 2.0 Identity

Автор Айзек Левин (Isaac Levin)

В этой статье показано, как перенести схему базы данных для приложений ASP.NET с помощью проверки подлинности членства в ASP.NET Core 2.0 Identity.

Проверка схемы членства

До ASP.NET 2.0 разработчикам было поручено создать весь процесс проверки подлинности и авторизации для своих приложений. С ASP.NET 2.0 членство было представлено, предоставляя стандартное решение для обработки безопасности в ASP.NET приложениях. Теперь разработчики смогли загрузить схему в базу данных SQL Server с помощью средства регистрации SQL Server ASP.NET (Aspnet_regsql.exe) (больше не поддерживается). После выполнения этой команды в базе данных были созданы следующие таблицы.

Чтобы перенести существующие приложения в ASP.NET Core 2.0 Identity, данные в этих таблицах необходимо перенести в таблицы, используемые новой Identity схемой.

схема ASP.NET Core Identity 2.0

ASP.NET Core 2.0 следует принципу, представленному Identity в ASP.NET 4.5. Хотя принцип является общим, реализация между платформами отличается, даже между версиями ASP.NET Core (см . проверку подлинности миграции и Identity ASP.NET Core 2.0).

Самый быстрый способ просмотра схемы для ASP.NET Core 2.0 Identity — создать новое приложение ASP.NET Core 2.0. Выполните следующие действия в Visual Studio 2017:

1. Выберите File>New>Project ( Файл > Создать > Проект).

2. Создайте проект ASP.NET Core Web Application с именем CoreIdentitySample.

3. Выберите ASP.NET Core 2.0 в раскрывающемся списке и выберите веб-приложение. Этот шаблон создает Razor приложение Pages . Перед нажатием кнопки "ОК" нажмите кнопку "Изменить проверку подлинности".

4. Выберите Identity для шаблонов. Наконец, нажмите кнопку "ОК", а затем "ОК". Visual Studio создает проект с помощью шаблона ASP.NET Core Identity .

5. Выберите Инструменты NuGet диспетчер пакетов диспетчер пакетов консоли> (PMC).>

6. Перейдите к корневому каталогу проекта в PMC и выполните команду Entity Framework (EF) CoreUpdate-Database.

   ASP.NET Core 2.0 Identity используется EF Core для взаимодействия с базой данных, в котором хранятся данные проверки подлинности. Чтобы созданное приложение работало, необходимо создать базу данных для хранения этих данных. После создания нового приложения самый быстрый способ проверки схемы в среде базы данных — создать базу данных с помощью EF Core миграций. Этот процесс создает базу данных либо локально, либо в другом месте, которая имитирует эту схему. Дополнительные сведения см. в предыдущей документации.

   EF Coreкоманды используют строка подключения для базы данных, указанной в appsettings.json. Следующая строка подключения предназначена для базы данных на localhost с именем asp-net-core-identity. В этом параметре EF Core настроено использование DefaultConnection строка подключения.

   {
     "ConnectionStrings": {
       "DefaultConnection": "Server=localhost;Database=aspnet-core-identity;Trusted_Connection=True;MultipleActiveResultSets=true"
     }
   }
   

1. Выберите view>SQL Server обозреватель объектов. Разверните узел, соответствующий имени базы данных, указанному в свойстве ConnectionStrings:DefaultConnectionappsettings.json.

   Команда Update-Database создала базу данных, указанную схемой, и все данные, необходимые для инициализации приложения. На следующем рисунке показана структура таблицы, созданная с помощью предыдущих шагов.

   

Перенос схемы

Существуют тонкие различия в структурах таблиц и полях для членства и ASP.NET Core Identity. Шаблон существенно изменился для проверки подлинности и авторизации с помощью ASP.NET и приложений ASP.NET Core. Ключевые объекты, которые по-прежнему используются с Identityпользователями и ролями. Ниже приведены таблицы сопоставления для пользователей, ролей и UserRoles.

Пользователи

IsLockedOut не сопоставляет LockoutEnabledс . IsLockedOut устанавливается, если у пользователя было слишком много неудачных имен входа и заблокировано в течение заданного времени. LockoutEnabled включает блокировку пользователя с слишком большим количеством неудачных попыток входа. Если у пользователя слишком много неудачных попыток входа, LockoutEnd устанавливается дата в будущем, и пользователь не сможет войти до этой даты. Если LockoutEnabled значение равно false, то пользователь никогда не заблокирован для слишком большого количества неудачных попыток входа. Для OWASP временная блокировка учетной записи после нескольких неудачных попыток слишком проста для атак DoS на законных пользователей.

Дополнительные сведения о блокировке см. в статье OWASP Testing for Weak Lock Out Mechanism.

Приложения, перенесенные в Identity это желание включить блокировку входа с ошибкой, должны иметь LockoutEnabled значение true в рамках миграции.

Роли

Роли пользователя

Ссылайтесь на предыдущие таблицы сопоставления при создании скрипта миграции для пользователей и ролей. В следующем примере предполагается, что на сервере базы данных есть две базы данных. Одна база данных содержит существующую схему и данные членства ASP.NET. Другая база данных CoreIdentitySample была создана с помощью описанных выше шагов. Дополнительные сведения см. в комментариях.

-- THIS SCRIPT NEEDS TO RUN FROM THE CONTEXT OF THE MEMBERSHIP DB
BEGIN TRANSACTION MigrateUsersAndRoles
USE aspnetdb

-- INSERT USERS
INSERT INTO CoreIdentitySample.dbo.AspNetUsers
            (Id,
             UserName,
             NormalizedUserName,
             PasswordHash,
             SecurityStamp,
             EmailConfirmed,
             PhoneNumber,
             PhoneNumberConfirmed,
             TwoFactorEnabled,
             LockoutEnd,
             LockoutEnabled,
             AccessFailedCount,
             Email,
             NormalizedEmail)
SELECT aspnet_Users.UserId,
       aspnet_Users.UserName,
       -- The NormalizedUserName value is upper case in ASP.NET Core Identity
       UPPER(aspnet_Users.UserName),
       -- Creates an empty password since passwords don't map between the 2 schemas
       '',
       /*
        The SecurityStamp token is used to verify the state of an account and
        is subject to change at any time. It should be initialized as a new ID.
       */
       NewID(),
       /*
        EmailConfirmed is set when a new user is created and confirmed via email.
        Users must have this set during migration to reset passwords.
       */
       1,
       aspnet_Users.MobileAlias,
       CASE
         WHEN aspnet_Users.MobileAlias IS NULL THEN 0
         ELSE 1
       END,
       -- 2FA likely wasn't setup in Membership for users, so setting as false.
       0,
       CASE
         -- Setting lockout date to time in the future (1,000 years)
         WHEN aspnet_Membership.IsLockedOut = 1 THEN Dateadd(year, 1000,
                                                     Sysutcdatetime())
         ELSE NULL
       END,
       aspnet_Membership.IsLockedOut,
       /*
        AccessFailedAccount is used to track failed logins. This is stored in
        Membership in multiple columns. Setting to 0 arbitrarily.
       */
       0,
       aspnet_Membership.Email,
       -- The NormalizedEmail value is upper case in ASP.NET Core Identity
       UPPER(aspnet_Membership.Email)
FROM   aspnet_Users
       LEFT OUTER JOIN aspnet_Membership
                    ON aspnet_Membership.ApplicationId =
                       aspnet_Users.ApplicationId
                       AND aspnet_Users.UserId = aspnet_Membership.UserId
       LEFT OUTER JOIN CoreIdentitySample.dbo.AspNetUsers
                    ON aspnet_Membership.UserId = AspNetUsers.Id
WHERE  AspNetUsers.Id IS NULL

-- INSERT ROLES
INSERT INTO CoreIdentitySample.dbo.AspNetRoles(Id, Name)
SELECT RoleId, RoleName
FROM aspnet_Roles;

-- INSERT USER ROLES
INSERT INTO CoreIdentitySample.dbo.AspNetUserRoles(UserId, RoleId)
SELECT UserId, RoleId
FROM aspnet_UsersInRoles;

IF @@ERROR <> 0
  BEGIN
    ROLLBACK TRANSACTION MigrateUsersAndRoles
    RETURN
  END

COMMIT TRANSACTION MigrateUsersAndRoles

После завершения предыдущего скрипта приложение ASP.NET Core Identity , созданное ранее, заполняется пользователями членства. Перед входом пользователям необходимо изменить пароли.

PageModel На странице входа, расположенной по адресу, удалите [EmailAddress] атрибут из свойства Email. Переименуйте его в UserName. Для этого требуется изменение, где бы ни EmailAddress упоминалось, в представлении и pageModel. Результат имеет следующий вид.

Следующие шаги

В этом руководстве вы узнали, как перенести пользователей из членства SQL в ASP.NET Core 2.0 Identity. Дополнительные сведения о ASP.NET Core Identityсм. в разделе "Общие сведения".Identity