|Integrert proxyautentisering: tjenestekontoer og identitetsovertakelse
|Undersøk sikkerhetskonteksten bak integrert proxyautentisering når samme applikasjon fungerer interaktivt, men feiler som webtjeneste eller planlagt prosess.
“Bruk Windows-legitimasjonen min” trenger et subjekt. I et skrivebordsprogram kan det være personen som kjører det. I en tjeneste kan det være tjenestens konto. I en webapplikasjon erstatter ikke en besøkendes vellykkede pålogging automatisk sikkerhetskonteksten til den utgående forespørselen.
Dette forklarer hvorfor en nettleser og serverkode på samme maskin kan få ulike resultater fra en proxy med integrert autentisering. De presenterer kanskje ulike identiteter.
Navngi identitetene før du endrer koden
- Personen som er pålogget skrivebordsnettleseren.
- Kontoen som er vert for applikasjonsprosessen.
- Enhver identitetsovertakelse som er aktiv for den utgående operasjonen.
- Kontoen som proxyen faktisk godtok eller avviste.
På .NETs støttede stier for integrert autentisering gjelder DefaultCredentials gjeldende sikkerhetskontekst. Det er ikke et globalt alias for alle som har åpnet en side på en annen maskin.
Hvis produktet bevisst opptrer som en bruker, trenger identitetsovertakelse og eventuelle krav om nettverksdelegering sitt eget støttede design. Å slå på en generisk bryter for bruk av standardlegitimasjon etablerer ikke det designet. Motsatt bør en bakgrunnsjobb som er ment å kjøre som en tjenesteidentitet, ikke være avhengig av at noen åpner en nettleser først.
Sammenlign den interaktive og den utrullede oppstarten uten hemmeligheter: kontokontekst, proxyendepunkt, annonsert metode og avvist identitet. Unngå å kopiere et skrivebordspassord inn i applikasjonen bare fordi det fikk én engangsforespørsel til å lykkes. Konfigurer kontoen applikasjonen skal bruke, og hold deretter det eierskapet synlig i utrullingsposten.