Олицетворение пользователя в Duende IdentityServer

Question

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

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

Вопросы, которые я прочитал до сих пор, включают:

• IdentityServer4 — как реализовать олицетворение
• Олицетворение с помощью IdentityServer с претензией субъекта для олицетворяемого пользователя
• Identityserver3 — олицетворение пользователя

Введение

По сути, у меня есть приложение ASP.NET Core Razor Pages и веб-API ASP.NET Core, оба защищены Duende IdentityServer.

Инженеры службы поддержки должны иметь возможность олицетворять клиентов в целях обслуживания ТОЛЬКО после того, как клиент дал согласие на олицетворение. Основной рабочий процесс:

• в приложении Razor Pages клиент активирует «Предоставить разрешение на олицетворение» в своих личных настройках.
• разрешение на олицетворение действительно в течение максимум 7 дней
• клиенты могут отозвать разрешения на олицетворение в любое время
• Затем инженеры службы поддержки могут войти в систему как любой клиент, предоставивший разрешение на олицетворение в бэк-офисе (без присутствия клиента, без стиля удаленного рабочего стола).

Подход 1:

Когда клиент предоставит разрешение, используйте механизм Token Exchange для обмена на новый токен доступа со сроком действия 7 дней. Сохраните этот токен в базе данных в IdentityServer и разрешите только инженерам службы поддержки получать токен доступа клиента через контроллер, используя идентификатор клиента, имя и т. д.

Хотя это сработает, мне не нравится идея хранения долгоживущих токенов доступа.

Подход 2:

Когда инженер службы поддержки входит в систему, на основе его личности отображается настраиваемый экран согласия, на котором можно выбрать клиентов для олицетворения, а затем войти в систему как выбранный клиент. Затем инженер службы поддержки получит токен доступа, а также токен идентификатора.

Самая большая проблема:

Существуют ли какие-либо точки/механизмы расширения в IdentityServer, которые можно подключить для управления процессом входа, чтобы превратить процесс входа в систему для входа в систему клиента, а не инженера службы поддержки? Возможно ли это сделать в IdentityServer?

Подход 3:

В Разрешить стороннику войти в систему как другой пользовательразделе Разрешить стороннику входить в систему как другому пользователю пользователь Mackie указал на высокоуровневое представление функции олицетворения. Вот шаги:

1. Перейдите к клиентскому приложению. Войдите, используя любые учетные данные.
2. Проверьте, существуют ли какие-либо разрешения на олицетворение (как они определяются, полностью зависит от вас)
3. Запрашивать выбор учетной записи для олицетворения (или просто продолжить от своего имени)
4. Войдите в систему как выбранная учетная запись (с записью оригинального актера)
5. Перенаправление для авторизации конечной точки
6. Выпуск токенов и перенаправление обратно в клиентское приложение

Как выполняются шаги с 4 по 6 на практике? Любые предложения по этому поводу?

Answer 1

У меня есть вопрос о проблеме в вашемApproach 2. Суть олицетворения пользователя фактически заключается в использовании «псевдо-токена» для олицетворения пользователя для проверки некоторых операций или разрешений. Или, может быть, вы просто хотите регистрировать все действия, выполняемые олицетворяемым пользователем?

Я думаю, может быть, вы можете перехватить вход в систему, как в этой ссылке. Но я думаю, что может быть лучше добавить к нему какую-то конкретную идентификацию, когда перехват успешен, вместо того, чтобы напрямую использовать информацию пользователя для входа в систему. Я думаю, что вход в систему клиента вместо инженера службы поддержки может больше не быть олицетворением пользователя ( просто личное мнение).

Кроме того, это упоминается в предоставленной вами ссылке. Судя по твоему описанию, что-то подходит:

acr_valuesпозволяет передавать дополнительную информацию, связанную с аутентификацией — в особых случаях identityserver следующие проприетарные значения acr_values:

idp:name_of_idpобходит экран входа в систему/домашнюю область и перенаправляет пользователя непосредственно к выбранному поставщику удостоверений (если это разрешено в конфигурации клиента)

tenant:name_of_tenantможет использоваться для передачи имени арендатора в интерфейс входа в систему

Для использования acr_values ​​вы можете обратиться к этой ссылке.

Другая ссылка:Рабочий процесс олицетворения.

Это только мое понимание и предложение, если у меня есть какое-то неправильное понимание, пожалуйста, исправьте его.