|Vërtetim i integruar përfaqësuesi: llogari shërbimi dhe imitim
|Shqyrtoni kontekstin e sigurisë pas vërtetimit të integruar të përfaqësuesit kur i njëjti aplikacion punon në mënyrë interaktive dhe dështon si shërbim web ose proces i planifikuar.
„Përdor kredencialet e mia të Windows“ ka nevojë për një subjekt. Në një program desktop mund të jetë personi që e ekzekuton. Në një shërbim mund të jetë llogaria e shërbimit. Në një aplikacion web, hyrja e suksesshme e një vizitori nuk e zëvendëson automatikisht kontekstin e sigurisë të kërkesës dalëse.
Kjo shpjegon pse një shfletues dhe kodi në anën e serverit në të njëjtën makinë mund të marrin rezultate të ndryshme nga një përfaqësues me vërtetim të integruar. Mund të jenë duke paraqitur identitete të ndryshme.
Emërtoni identitetet përpara se të ndryshoni kodin
- Personi i futur në shfletuesin e desktopit.
- Llogaria që strehon procesin e aplikacionit.
- Çdo identitet i imituar aktiv për operacionin dalës.
- Llogaria që përfaqësuesi pranoi ose refuzoi vërtet.
Në rrugët e vërtetimit të integruar të mbështetura nga .NET, DefaultCredentials ka të bëjë me kontekstin aktual të sigurisë. Nuk është një pseudonim global për këdo që hapi një faqe në një makinë tjetër.
Nëse produkti vepron me qëllim si përdorues, imitimi dhe çdo kërkesë për delegim rrjeti kanë nevojë për dizajnin e tyre të mbështetur. Ndërprerja e një çelësi të përgjithshëm të përdorimit të kredencialeve të parazgjedhura nuk e vendos atë dizajn. Në të kundërt, një punë në sfond e menduar të ekzekutohet si identitet shërbimi nuk duhet të varet nga hapja e një shfletuesi nga dikush më parë.
Krahasoni nisjen interaktive dhe atë të vendosur pa sekretet: konteksti i llogarisë, pika fundore e përfaqësuesit, metoda e shpallur dhe identiteti i refuzuar. Shmangni kopjimin e një fjalëkalimi desktop në aplikacion vetëm sepse bëri që një kërkesë e vetme të kishte sukses. Konfiguroni llogarinë që aplikacioni duhet të përdorë dhe më pas mbani atë pronësi të dukshme në regjistrin e vendosjes.