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