IdentityServer ClaimsIdentity для олицетворенного WindowsIdentity

Question

У меня есть настройка IdentityServer для подключения к внешнему серверу ADFS. Я могу войти в систему и получить токен доступа через OAuth2 / OpenId Connect. As pNet .Core WebApi работает в пуле приложений IIS с пользователем, у которого включено делегирование Kerberos (должен иметь, не знаю, как это проверить, поскольку я не в инфраструктуре).

Чего я хочу достичь состоит в том, что ClaimsIdentity, который я получаю от IdentityServer в WebApi, преобразуется обратно в WindowsIdentity с использованием олицетворения без пароля. Достаточно просто имени пользователя. С фактическим олицетворением WindowsIdentity я должен затем войти в базу данных и внести некоторые изменения.

Я не уверен, возможно ли это вообще, но я уже довольно давно борюсь с этим.

Я взял это как основу для реализации олицетворения. Единственная проблема, с которой я столкнулся, заключается в том, что Context.User.Identity возвращает не WindowsIdentity, а ClaimsIdentity.

Другой подход, который я пробовал, - это использование var user = new WindowsIdentity(username);, где имя пользователя будет UPN. Это создает личность с ImpersonationLevel.Identity вместо ImpersonationLevel.Impersonated. Когда я запускаю WindowsIdentity.RunImpersonated() с этим токеном доступа пользователей, при загрузке необходимых сборок будет выдан отказ в доступе или исключение IOException.

Итак, первый вопрос: как мне проверить, имеет ли пользователь IIS AppPool правильные права делегирования Kerberos ?

Второй вопрос: можно ли вообще выдать себя за пользователя только с логином?

Answer 1

То, что вы описываете, - это делегирование с «любым» методом аутентификации. С точки зрения протокола это называется Service-for-User-to-Proxy. Это требует, чтобы учетной записи службы было предоставлено это право, и вам необходимо проверить, что учетная запись службы Active Directory настроена для этого. Вам также необходимо указать, какие службы могут получать олицетворенные соединения.

После того, как вы настроили учетную запись службы, вам следует перезапустить компьютер, на котором запущен код (в памяти происходит отрицательное кэширование, что требует времени до истечения времени ожидания). Если ваше приложение работает в IIS, ваша учетная запись службы уже должна быть настроена для использования правильных Windows локальных прав для олицетворения.

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