В   Core для многопользовательской архитектуры создаются отдельные модели пользователей, наследуемые от 

Реализация в
 
Порядок вызова
 
IdentityUser. Это позволяет разграничить роли, такие как туристы, партнеры, агенты и администраторы. Каждая модель имеет свою логику и свойства, что обеспечивает гибкость в управлении доступом и функциональностью. ApplicationUser служит базовой моделью, а ApplicationObject – для общих свойств партнеров и агентов. 
Изображение носит иллюстративный характер
Реализация в
Program.cs включает добавление AddIdentity и AddIdentityCore для каждого типа пользователя. Важно отметить, что настройка RequireConfirmedEmail в AddIdentityCore применяется к последнему объявленному типу пользователя, переопределяя предыдущие настройки. Простым выходом из этой ситуации, является установка EmailConfirmed=true для пользователей, где подтверждение электронной почты не требуется. Порядок вызова
AddIdentity и ConfigureApplicationCookie критически важен. ConfigureApplicationCookie должен вызываться после AddIdentity для корректной настройки Cookies и обработки редиректов. Неправильный порядок может привести к проблемам с аутентификацией и управлением Cookies. CustomUserClaimsPrincipalFactory извлекает роли пользователей для использования в механизмах авторизации через атрибут [Authorize]. Этот подход позволяет динамически задавать права доступа на основе ролей, хранящихся в пользовательских моделях. Это делает код более управляемым и безопасным.













