|Integrerad proxyautentisering: tjänstekonton och identitetsövertagande
|Undersök säkerhetskontexten bakom integrerad proxyautentisering när samma program fungerar interaktivt men misslyckas som webbtjänst eller schemalagd process.
”Använd mina Windows-autentiseringsuppgifter” behöver ett subjekt. I ett skrivbordsprogram kan det vara personen som kör det. I en tjänst kan det vara tjänstens konto. I en webbapplikation ersätter inte en besökarens lyckade inloggning automatiskt säkerhetskontexten för den utgående begäran.
Detta förklarar varför en webbläsare och serverkod på samma maskin kan få olika resultat från en proxy med integrerad autentisering. De presenterar kanske olika identiteter.
Namnge identiteterna innan du ändrar koden
- Personen som är inloggad i skrivbordswebbläsaren.
- Kontot som är värd för applikationsprocessen.
- Varje övertagen identitet som är aktiv för den utgående åtgärden.
- Kontot som proxyn faktiskt accepterade eller avvisade.
På .NET:s stödda vägar för integrerad autentisering gäller DefaultCredentials den aktuella säkerhetskontexten. Det är inte ett globalt alias för alla som har öppnat en sida på en annan maskin.
Om produkten medvetet agerar som en användare behöver identitetsövertagande och eventuella krav på nätverksdelegering en egen stödd design. Att slå på en generisk brytare för användning av standardautentiseringsuppgifter etablerar inte den designen. Omvänt bör ett bakgrundsjobb som är avsett att köras som en tjänsteidentitet inte vara beroende av att någon först öppnar en webbläsare.
Jämför den interaktiva och den utrullade starten utan hemligheter: kontokontext, proxy-slutpunkt, annonserad metod och avvisad identitet. Undvik att kopiera ett skrivbordslösenord till applikationen bara för att det fick en engångsbegäran att lyckas. Konfigurera kontot som applikationen ska använda och håll sedan det ägarskapet synligt i utrullningsposten.