|Integrēta starpniekservera autentifikācija: pakalpojumu konti un identitātes uzurpēšana
|Izpētiet drošības kontekstu aiz integrētās starpniekservera autentifikācijas, kad viena un tā pati lietojumprogramma darbojas interaktīvi, bet neizdodas kā tīmekļa pakalpojums vai ieplānots process.
“Izmantot manus Windows akreditācijas datus” vajag subjektu. Darbvirsmas programmā tas var būt cilvēks, kas to palaiž. Pakalpojumā tas var būt pakalpojuma konts. Tīmekļa lietojumprogrammā apmeklētāja veiksmīga pieteikšanās automātiski neaizstāj izejošā pieprasījuma drošības kontekstu.
Tas izskaidro, kāpēc pārlūkprogramma un servera puses kods tajā pašā mašīnā var saņemt atšķirīgus rezultātus no starpniekservera ar integrētu autentifikāciju. Tie, iespējams, uzrāda atšķirīgas identitātes.
Nosauciet identitātes pirms koda maiņas
- Cilvēks, kas pieteicies darbvirsmas pārlūkprogrammā.
- Konts, kas mitina lietojumprogrammas procesu.
- Jebkura uzurpētā identitāte, kas ir aktīva izejošajai darbībai.
- Konts, ko starpniekserveris faktiski pieņēma vai noraidīja.
.NET atbalstītajos integrētās autentifikācijas ceļos DefaultCredentials attiecas uz pašreizējo drošības kontekstu. Tas nav globāls aizstājvārds ikvienam, kas atvēra lapu citā mašīnā.
Ja produkts apzināti darbojas kā lietotājs, identitātes uzurpēšanai un jebkurām tīkla deleģēšanas prasībām ir vajadzīgs savs atbalstīts dizains. Vispārīga noklusējuma akreditācijas datu lietošanas slēdža ieslēgšana šo dizainu neizveido. Pretēji, fona uzdevumam, kas paredzēts darbam kā pakalpojuma identitātei, nevajadzētu būt atkarīgam no tā, ka kāds vispirms atver pārlūkprogrammu.
Salīdziniet interaktīvo un izvietoto palaišanu pēc slepeno datu noņemšanas: konta konteksts, starpniekservera galapunkts, paziņotā metode un noraidītā identitāte. Izvairieties kopēt darbvirsmas paroli lietojumprogrammā tikai tāpēc, ka tā ļāva vienam vienreizējam pieprasījumam izdoties. Konfigurējiet kontu, ko lietojumprogrammai paredzēts izmantot, un pēc tam saglabājiet šo piederību redzamu izvietošanas ierakstā.