|Інтегрована автентифікація через проксі: службові облікові записи та уособлення
|Дослідіть контекст безпеки за інтегрованою автентифікацією через проксі, коли той самий застосунок працює інтерактивно, але зазнає збою як вебслужба чи запланований процес.
«Використовувати мої облікові дані Windows» потребує суб'єкта. У настільній програмі це може бути людина, яка її запускає. У службі це може бути обліковий запис служби. У вебзастосунку успішний вхід відвідувача не замінює автоматично контекст безпеки вихідного запиту.
Це пояснює, чому браузер і серверний код на одній машині можуть отримувати різні результати від проксі з інтегрованою автентифікацією. Можливо, вони подають різні ідентичності.
Назвіть ідентичності, перш ніж змінювати код
- Людина, яка ввійшла в настільний браузер.
- Обліковий запис, у якому розміщено процес застосунку.
- Будь-яка уособлена ідентичність, активна для вихідної операції.
- Обліковий запис, який проксі справді прийняв або відхилив.
На підтримуваних .NET шляхах інтегрованої автентифікації DefaultCredentials стосується поточного контексту безпеки. Це не глобальний псевдонім для кожного, хто відкрив сторінку на іншій машині.
Якщо продукт навмисно діє як користувач, уособлення та будь-які вимоги до мережевого делегування потребують власного підтримуваного дизайну. Увімкнення загального перемикача використання типових облікових даних не створює такого дизайну. І навпаки, фонове завдання, призначене для роботи як ідентичність служби, не повинно залежати від того, що хтось спершу відкриє браузер.
Порівняйте інтерактивний і розгорнутий запуск, прибравши секрети: контекст облікового запису, кінцеву точку проксі, оголошений метод і відхилену ідентичність. Уникайте копіювання настільного пароля в застосунок лише тому, що це дозволило виконати один одноразовий запит. Налаштуйте обліковий запис, який застосунок має використовувати, а потім тримайте цю належність видимою в записі розгортання.