|Интегрирано прокси удостоверяване: служебни акаунти и имперсонация
|Прегледайте контекста на сигурност зад интегрираното прокси удостоверяване, когато едно и също приложение работи интерактивно, но се проваля като уеб услуга или планиран процес.
“Използвай моите Windows идентификационни данни” се нуждае от субект. В програма за работен плот това може да е човекът, който я стартира. В услуга това може да е акаунтът на услугата. В уеб приложение успешният вход на посетител не замества автоматично контекста на сигурност на изходящата заявка.
Това обяснява защо браузър и сървърен код на една и съща машина могат да получат различни резултати от прокси с интегрирано удостоверяване. Те може да представят различни самоличности.
Назовайте самоличностите, преди да променяте кода
- Човекът, влязъл в браузъра на работния плот.
- Акаунтът, който хоства процеса на приложението.
- Всяка имперсонирана самоличност, активна за изходящата операция.
- Акаунтът, който проксито действително е приело или отхвърлило.
По поддържаните от .NET пътища за интегрирано удостоверяване DefaultCredentials се отнася до текущия контекст на сигурност. Това не е глобален псевдоним за всеки, който е отворил страница на друга машина.
Ако продуктът съзнателно действа като потребител, имперсонацията и всички изисквания за мрежово делегиране се нуждаят от собствен поддържан дизайн. Включването на общ превключвател за използване на данни по подразбиране не установява такъв дизайн. Обратно, фонова задача, предназначена да работи като служебна самоличност, не трябва да зависи от това някой първо да отвори браузър.
Сравнете интерактивното и разгърнатото стартиране, след като премахнете тайните: контекст на акаунта, крайна точка на проксито, обявен метод и отхвърлена самоличност. Избягвайте копирането на парола от работния плот в приложението само защото това е направило една еднократна заявка успешна. Настройте акаунта, който приложението трябва да използва, и след това поддържайте тази собственост видима в записа за разгръщане.