|Integrisana proxy autentifikacija: servisni računi i lažno predstavljanje
|Ispitajte bezbednosni kontekst iza integrisane proxy autentifikacije kada ista aplikacija radi interaktivno, a zakaže kao veb usluga ili zakazani proces.
„Koristi moje Windows akreditive“ zahteva subjekta. U stonoj aplikaciji to može biti osoba koja je pokreće. U servisu to može biti nalog servisa. U veb aplikaciji uspešna prijava posetioca ne zamenjuje automatski bezbednosni kontekst odlaznog zahteva.
To objašnjava zašto pregledač i serverski kod na istom računaru mogu dobiti različite rezultate od proxyja sa integrisanom autentifikacijom. Možda predstavljaju različite identitete.
Imenujte identitete pre nego što promenite kod
- Osoba prijavljena u stoni pregledač.
- Nalog koji hostuje proces aplikacije.
- Svaki lažni identitet aktivan za odlaznu operaciju.
- Nalog koji je proxy zaista prihvatio ili odbio.
Na .NET-ovim podržanim putevima integrisane autentifikacije DefaultCredentials se odnosi na trenutni bezbednosni kontekst. To nije globalni pseudonim za svakoga ko je otvorio stranicu na drugom računaru.
Ako proizvod namerno deluje kao korisnik, lažno predstavljanje i svi zahtevi za mrežno delegiranje trebaju sopstveni podržani dizajn. Uključivanje opšteg prekidača za korišćenje podrazumevanih akreditiva ne uspostavlja taj dizajn. Suprotno tome, pozadinski posao namenjen radu kao servisni identitet ne bi trebalo da zavisi od toga da neko prvo otvori pregledač.
Uporedite interaktivno i raspoređeno pokretanje nakon uklanjanja tajni: kontekst naloga, krajnju tačku proxyja, objavljenu metodu i odbijeni identitet. Izbegnite kopiranje stone lozinke u aplikaciju samo zato što je to omogućilo jedan jednokratni zahtev. Konfigurišite nalog koji aplikacija treba da koristi i zatim održavajte to vlasništvo vidljivim u zapisu o raspoređivanju.