У меня есть требование разрешить нашим пользователям внутренней поддержки выдавать себя за наших клиентов-пользователей.
В настоящее время я использую IdentityServer4, Implicit Flow и OIDC Client.
Ресурсы пока найдены.
Учитывая, что в Интернете есть ограниченные ресурсы, есть ли какие-либо предложения о том, как я могу / должен реализовать олицетворение с помощью IdentityServer4?
IdentityServer4 не предписывает никаких провайдеров аутентификации. Он просто действует как одно целое для других клиентов OIDC. Вот почему вы можете использовать сторонних поставщиков услуг входа в систему, локальные учетные записи и все остальное.
Создайте ImpersonationController на своем IdentityServer. Убедитесь, что только ваши администраторы могут получить доступ к этой странице.
[Authorize(Policy = "CanImpersonate")]
Создайте страницу, на которой вы можете ввести идентификатор пользователя, за которого администратор хочет выдать себя. При публикации этой формы с предполагаемым идентификатором пользователя используйте класс SignInManager<> для входа в систему текущего пользователя.
Вы даже можете создать раскрывающийся список, за какого внешнего поставщика входа вы хотите выдать себя, если это важно для вас. Используйте метод ExternalLoginSignInAsync, в противном случае - простой метод SignInAsync(user, false).
После этого вы уже вошли в систему как этот пользователь на Identity Server. Когда ваши клиентские приложения запрашивают вход, IdentityServer заметит ваш «поддельный» сеанс и немедленно перенаправит обратно клиенту с вашей учетной записью, в которую вы вошли в систему.
Теперь вы олицетворяете этого пользователя в своем клиентском приложении и на IdentityServer.
Если вы выйдете из системы на IdentityServer, вы снова будете «переведены» на свою ранее вошедшую учетную запись (если все еще вошли в систему под другим идентификатором), или вам нужно будет снова войти в систему как фактическая учетная запись администратора.
Очевидно, это тема для дискуссий. Я предполагаю, что вы хотите добавить эту функцию, чтобы вы могли воспроизводить проблемы пользователя или выполнять какие-либо действия как пользователь.
Если вы делаете это без ведома пользователей, будьте очень осторожны с побочными эффектами любых действий, выполняемых во время олицетворения. Отправляются ли электронные письма или аналогичные уведомления.
Идя по этому пути, можно потерять много доверия.
Это тоже забота о конфиденциальности. Кто может получить доступ к деталям. Какие подробности раскрываются при выдаче себя за пользователя на вашей платформе.
Не выдавайте себя за пользователей.
Внедрите управляемый способ, с помощью которого ваши администраторы могут выполнять необходимую работу. Тогда у вас будет постоянный журнал аудита, и что бы ни делал с вашей системой вошедший в систему пользователь, вы можете быть уверены, что эту учетную запись олицетворял именно этот пользователь, а не ваш администратор.
Вероятно, не будет пытаться встроить функцию олицетворения в основные библиотеки IdentityServer4. Вам действительно нужна небольшая структура данных для хранения вашего олицетворенного UserId и служба для проверки этого. Это фундаментальная функция, на основе которой должно разрабатываться ваше приложение.
Также учтите, что вам могут понадобиться функции суперпользователя, которые все еще присутствуют, даже если вы выдаете себя за другое лицо (например, не за другое лицо).
вы можете реализовать IResourceOwnerValidation и проверять пользователей службы поддержки по-своему. например, сгенерируйте код для конкретного пользователя и передайте его пользователю поддержки, а затем в своей реализации проверьте свой пароль с этим кодом.
