|Integreret proxygodkendelse: tjenestekonti og efterligning
|Undersøg sikkerhedskonteksten bag integreret proxygodkendelse, når den samme applikation virker interaktivt og fejler som en webtjeneste eller planlagt proces.
“Brug mine Windows-legitimationsoplysninger” kræver et subjekt. I et skrivebordsprogram kan det være den person, der kører det. I en tjeneste kan det være tjenestens konto. I en webapplikation erstatter en besøgendes vellykkede logon ikke automatisk den udgående anmodnings sikkerhedskontekst.
Det forklarer, hvorfor en browser og serverkode på samme maskine kan få forskellige resultater fra en proxy med integreret godkendelse. De præsenterer muligvis forskellige identiteter.
Navngiv identiteterne, før du ændrer koden
- Den person, der er logget på skrivebordsbrowseren.
- Den konto, der hoster applikationsprocessen.
- Enhver efterlignet identitet, der er aktiv for den udgående handling.
- Den konto, som proxyen faktisk accepterede eller afviste.
På .NET's understøttede stier for integreret godkendelse vedrører DefaultCredentials den aktuelle sikkerhedskontekst. Det er ikke et globalt alias for enhver, der har åbnet en side på en anden maskine.
Hvis produktet bevidst optræder som en bruger, kræver efterligning og eventuelle krav om netværksdelegering deres eget understøttede design. At slå en generisk kontakt til brug af standardlegitimationsoplysninger til etablerer ikke det design. Omvendt bør et baggrundsjob, der er beregnet til at køre som en tjenesteidentitet, ikke afhænge af, at nogen først åbner en browser.
Sammenlign den interaktive og den udrullede start uden hemmeligheder: kontokontekst, proxyendepunkt, annonceret metode og afvist identitet. Undgå at kopiere en skrivebordsadgangskode ind i applikationen, blot fordi det fik en enkeltstående anmodning til at lykkes. Konfigurer den konto, applikationen skal bruge, og hold derefter det ejerskab synligt i udrulningsposten.