|Інтэграваная аўтэнтыфікацыя праз проксі: сэрвісныя ўліковыя запісы і імітацыя
|Разгледзьце кантэкст бяспекі за інтэграванай аўтэнтыфікацыяй праз проксі, калі адна і тая ж праграма працуе інтэрактыўна, але збіваецца як вэб-сэрвіс або планаваны працэс.
“Выкарыстаць мае ўліковыя даныя Windows” патрабуе суб'екта. У праграме для працоўнага стала гэта можа быць чалавек, які яе запускае. У сэрвісе гэта можа быць уліковы запіс сэрвісу. У вэб-праграме паспяховы ўваход наведвальніка не замяняе аўтаматычна кантэкст бяспекі зыходнага запыту.
Гэта тлумачыць, чаму браўзер і код на баку сервера на той жа машыне могуць атрымліваць розныя вынікі ад проксі з інтэграванай аўтэнтыфікацыяй. Яны могуць прад'яўляць розныя ідэнтычнасці.
Назвіце ідэнтычнасці перад змяненнем кода
- Чалавек, які ўвайшоў у браўзер на працоўным стале.
- Уліковы запіс, які размяшчае працэс праграмы.
- Любая імітаваная ідэнтычнасць, актыўная для зыходнай аперацыі.
- Уліковы запіс, які проксі сапраўды прыняў або адхіліў.
На шляхах інтэграванай аўтэнтыфікацыі, якія падтрымлівае .NET, DefaultCredentials датычыцца бягучага кантэксту бяспекі. Гэта не глабальны псеўданім для ўсяго, хто адкрыў старонку на іншай машыне.
Калі прадукт наўмысна дзейнічае як карыстальнік, імітацыя і любыя патрабаванні да дэлегавання ў сетцы патрабуюць уласнага падтрыманага дызайну. Уключэнне агульнага пераключальніка выкарыстання стандартных уліковых даных не стварае такі дызайн. Наадварот, фонавая задача, прызначаная для працы ад імя сэрвіснай ідэнтычнасці, не павінна залежаць ад таго, што хтосьці спачатку адкрые браўзер.
Параўнайце інтэрактыўны і разгорнуты запуск, прыбраўшы сакрэты: кантэкст уліковага запісу, канчатковы пункт проксі, абвешчаны метад і адхіленую ідэнтычнасць. Пазбягайце капіявання пароля працоўнага стала ў праграму толькі таму, што гэта дазволіла выканаць адзін разавы запыт. Наладзьце ўліковы запіс, які праграма павінна выкарыстоўваць, і затым трымайце гэтую прыналежнасць бачнай у запісе разгортвання.