|Geïntegreerde proxy-verifikasie: diensrekeninge en nabootsing
|Ondersoek die sekuriteitskonteks agter geïntegreerde proxy-verifikasie wanneer dieselfde toepassing interaktief werk en as 'n webdiens of geskeduleerde proses misluk.
“Gebruik my Windows-referensies” het 'n subjek nodig. In 'n lessenaarprogram kan dit die persoon wees wat dit bestuur. In 'n diens kan dit die diens se rekening wees. In 'n webtoepassing vervang 'n besoeker se suksesvolle aanmelding nie outomaties die uitgaande versoek se sekuriteitskonteks nie.
Dit verduidelik waarom 'n blaaier en bedienerkant-kode op dieselfde masjien verskillende resultate van 'n geïntegreerde-verifikasie-proxy kan kry. Hulle wys dalk verskillende identiteite.
Noem die identiteite voordat jy die kode verander
- Die persoon wat by die lessenaarblaaier aangemeld is.
- Die rekening wat die toepassingsproses huisves.
- Enige nagebootste identiteit wat vir die uitgaande bewerking aktief is.
- Die rekening wat die proxy werklik aanvaar of verwerp het.
Op .NET se ondersteunde geïntegreerde-verifikasie-roetes hou DefaultCredentials verband met die huidige sekuriteitskonteks. Dit is nie 'n globale alias vir elkeen wat 'n bladsy op 'n ander masjien oopgemaak het nie.
As die produk doelbewus as 'n gebruiker optree, het nabootsing en enige netwerkdelegeringsvereistes hul eie ondersteunde ontwerp nodig. Om 'n generiese skakelaar vir die gebruik van verstekreferensies aan te skakel, vestig nie daardie ontwerp nie. Omgekeerd behoort 'n agtergrondtaak wat bedoel is om as 'n diensidentiteit te loop, nie daarvan afhanklik te wees dat iemand eers 'n blaaier oopmaak nie.
Vergelyk die interaktiewe en die ontplooide lansering met geheims uitgelaat: rekeningkonteks, proxy-eindpunt, geadverteerde metode en verwerpte identiteit. Vermy om 'n lessenaarwagwoord in die toepassing te kopieer bloot omdat dit een eenmalige versoek laat slaag het. Stel die rekening op wat die toepassing veronderstel is om te gebruik, en hou dan daardie eienaarskap sigbaar in die ontplooiingsrekord.