|Autentificare proxy integrată: conturi de serviciu și impersonare
|Examinați contextul de securitate din spatele autentificării proxy integrate atunci când aceeași aplicație funcționează interactiv și eșuează ca serviciu web sau proces programat.
„Folosește acreditările mele Windows” are nevoie de un subiect. Într-un program de birou, acesta poate fi persoana care îl rulează. Într-un serviciu, poate fi contul serviciului. Într-o aplicație web, autentificarea reușită a unui vizitator nu înlocuiește automat contextul de securitate al cererii de ieșire.
Aceasta explică de ce un browser și codul de pe partea serverului de pe aceeași mașină pot primi rezultate diferite de la un proxy cu autentificare integrată. Este posibil să prezinte identități diferite.
Numiți identitățile înainte de a modifica codul
- Persoana autentificată în browserul de birou.
- Contul care găzduiește procesul aplicației.
- Orice identitate impersonată activă pentru operațiunea de ieșire.
- Contul pe care proxy-ul l-a acceptat sau respins efectiv.
Pe căile de autentificare integrată acceptate de .NET, DefaultCredentials se referă la contextul de securitate curent. Nu este un alias global pentru oricine a deschis o pagină pe altă mașină.
Dacă produsul acționează intenționat ca utilizator, impersonarea și orice cerințe de delegare a rețelei au nevoie de propriul design acceptat. Activarea unui comutator generic de utilizare a acreditărilor implicite nu stabilește acel design. Invers, o sarcină de fundal menită să ruleze ca identitate de serviciu nu ar trebui să depindă de deschiderea prealabilă a unui browser de către cineva.
Comparați pornirea interactivă și cea implementată fără secrete: contextul contului, punctul final al proxy-ului, metoda anunțată și identitatea respinsă. Evitați copierea unei parole de birou în aplicație doar pentru că a făcut ca o cerere unică să reușească. Configurați contul pe care aplicația ar trebui să îl utilizeze, apoi păstrați acea proprietate vizibilă în evidența implementării.