Отношения потоков процессов Microsoft Identtiy и Identity Server 4
Я работаю над созданием серии микросервисов с использованием Aspnet Core. Мобильное приложение, настольное приложение и веб-приложение будут использовать службы через Http REST API.
Для аутентификации пользователей я использую платформу Aspnet Core Identity, но я раскрываю создание учетных записей пользователей через REST API. Клиенты выполняют вызов REST с учетными данными, а мой API использует API-интерфейсы Microsoft Identity для подготовки пользователя. Пользователю будет разрешено обращаться к отдельным серверам ресурсов с помощью сервера аутентификации, использующего IdentityServer4.
У меня есть два вопроса, по которым я не смог найти четких указаний с точки зрения безопасности. Должен ли проект Aspnet Core, который использует Microsoft Identity для создания пользователей, находиться в независимом проекте Aspnet Core от проекта, который обрабатывает аутентификацию через IdentityServer4? Есть ли недостатки при разделении двух, которые мне нужно учитывать?
В Microsoft Identity API есть шаблоны и Razor Views, которые можно использовать для обработки аутентификации с точки зрения сервера, включая перенаправления при создании учетной записи или входе в систему и т. д. Если я делаю все через SPA или собственные приложения на стороне клиента, Есть ли что-то плохое в том, чтобы просто предоставить POST API, который принимает информацию о пользователе, создает учетную запись через UserManager<T> и возвращает UserId?
Я хочу предоставить специальную страницу входа, похожую на FB/Google/Twitter и т. д., чтобы аутентификация выполнялась в любом приложении, которое хочет авторизовать пользователя для моих услуг. Однако обычно я не рассматриваю создание учетной записи как часть процесса OAuth. Является ли типичным то, что вы разрешаете перенаправление на страницу создания учетной записи, которая перенаправляет обратно к клиенту после успешного создания учетной записи, или этот процесс обычно используется только для аутентификации через потоки OAuth?
Ответы 2
Я бы предложил рассмотреть возможность использования одной службы для IDS4 и ASP.NET Identity, поскольку их можно интегрировать и предоставить вам полную функциональность, которую вы ищете (авторизация и управление пользователями).
В IDS4 есть примеры и хорошая документация по этому поводу.
Для меня, я думаю, разделение их было бы чрезмерным проектированием.
один пример: когда IDS4 генерирует токен доступа для пользователя, вы должны получить утверждения, роли и проверить имя пользователя и пароль, все это хранится в ASP.NET Identity.
Поэтому для получения более подробной информации вы можете проверить документы Identity Server 4: http://docs.identityserver.io/en/latest/quickstarts/0_overview.html
или я с удовольствием проверю свой небольшой пост в блоге, который я попытался дать более подробно и шаг за шагом. https://feras.blog/how-to-use-asp-net-identity-and-identityserver4-in-your-solution/
Начните со ссылки на IDS4, потому что этого может быть достаточно :)
Спасибо, тогда я их укрупню. С помощью микросервисов я пытаюсь избежать совместного использования баз данных между сервисами. Если я разделю их, мне придется совместно использовать базу данных, что будет противоречить шаблону проектирования микросервисов.
Добро пожаловать. Да. Именно, избегание совместного использования базы данных — еще одна важная причина, по которой они должны оставаться одной.
Главный момент при размышлении о пользовательском интерфейсе управления безопасностью заключается в том, как защитить этот пользовательский интерфейс. И самый безопасный подход на сегодняшний день — это аутентификация на основе файлов cookie с файлами cookie того же сайта (способ, который MVC использует по умолчанию). Учтите это при выборе бессерверного шаблона SPA. Для целей управления приложение со строгой серверной частью намного безопаснее, чем доступ к распределенным API-интерфейсам на основе токенов.
Что касается хостинга приложений, @VidmantasBlazevicius абсолютно прав, единственной стратегии нет: разместить все сервисы в одном приложении проще, поэтому оно лучше подходит для средненагруженных систем. Но с увеличением количества пользователей и запросов на проверку подлинности может потребоваться масштабирование, и отделение пользовательского интерфейса управления от проверки подлинности — один из способов справиться с этим.
В подходе, который вы рассматриваете, нет ничего плохого, и вы можете использовать IDS4 как отдельный проект или тот же проект, что и управление пользователями. Все это зависит от вас, поэтому вы не нашли много информации об этом, потому что это слишком широкий и самоуверенный вопрос.