|Интегрирана автентикација преку прокси: сервисни сметки и претставување како друг
|Испитајте го безбедносниот контекст зад интегрираната автентикација преку прокси кога истата апликација работи интерактивно, но не успева како веб-услуга или закажан процес.
„Користи ги моите Windows-поставки“ бара субјект. Во десктоп-програма тоа може да биде лицето што ја извршува. Во услуга тоа може да биде сметката на услугата. Во веб-апликација, успешната најава на посетител не го заменува автоматски безбедносниот контекст на излезното барање.
Ова објаснува зошто прелистувач и серверски код на истата машина можат да добијат различни резултати од прокси со интегрирана автентикација. Можеби претставуваат различни идентитети.
Именувајте ги идентитетите пред да го менувате кодот
- Лицето најавено во десктоп-прелистувачот.
- Сметката што го хостира процесот на апликацијата.
- Секој претставен идентитет активен за излезната операција.
- Сметката што проксито навистина ја прифатило или одбило.
На патеките за интегрирана автентикација поддржани од .NET, DefaultCredentials се однесува на тековниот безбедносен контекст. Тоа не е глобален псевдоним за секој што отворил страница на друга машина.
Ако производот намерно дејствува како корисник, претставувањето како друг и сите барања за мрежно делегирање бараат сопствен поддржан дизајн. Вклучувањето општ преклопник за користење стандардни поставки не воспоставува таков дизајн. Обратно, позадинска задача наменета да работи како сервисен идентитет не треба да зависи од тоа некој прво да отвори прелистувач.
Споредете го интерактивното и распореденото стартување откако ќе ги отстраните тајните: контекст на сметката, крајна точка на проксито, објавен метод и одбиен идентитет. Избегнувајте копирање десктоп-лозинка во апликацијата само затоа што така успеа едно еднократно барање. Конфигурирајте ја сметката што апликацијата треба да ја користи, потоа држете го тоа сопствеништво видливо во записот за распоредување.