|Integroitu välityspalvelimen todennus: palvelutilit ja identiteetin esittäminen
|Tarkastele integroidun välityspalvelimen todennuksen taustalla olevaa tietoturvakontekstia, kun sama sovellus toimii vuorovaikutteisesti mutta epäonnistuu verkkopalveluna tai ajastettuna prosessina.
“Käytä Windows-tunnuksiani” tarvitsee subjektin. Työpöytäohjelmassa se voi olla henkilö, joka sitä suorittaa. Palvelussa se voi olla palvelun tili. Verkkosovelluksessa kävijän onnistunut kirjautuminen ei automaattisesti korvaa lähtevän pyynnön tietoturvakontekstia.
Tämä selittää, miksi selain ja palvelinpuolen koodi samalla koneella voivat saada eri tuloksia integroidun todennuksen välityspalvelimelta. Ne saattavat esittää eri identiteettejä.
Nimeä identiteetit ennen koodin muuttamista
- Henkilö, joka on kirjautunut työpöytäselaimeen.
- Tili, joka isännöi sovellusprosessia.
- Mikä tahansa lähtevää toimintoa varten aktiivinen esitetty identiteetti.
- Tili, jonka välityspalvelin todella hyväksyi tai hylkäsi.
.NET:n tukemilla integroidun todennuksen poluilla DefaultCredentials koskee nykyistä tietoturvakontekstia. Se ei ole yleinen alias kaikille, jotka avasivat sivun toisella koneella.
Jos tuote toimii tarkoituksella käyttäjänä, identiteetin esittäminen ja mahdolliset verkkosiirron vaatimukset tarvitsevat oman tuetun suunnittelunsa. Yleisen oletustunnusten käytön kytkimen päälle kytkeminen ei vahvista tätä suunnittelua. Päinvastoin, taustatehtävän, joka on tarkoitettu ajettavaksi palveluidentiteettinä, ei pitäisi riippua siitä, että joku avaa ensin selaimen.
Vertaa vuorovaikutteista ja käyttöönotettua käynnistystä ilman salaisuuksia: tilin konteksti, välityspalvelimen päätepiste, ilmoitettu menetelmä ja hylätty identiteetti. Vältä työpöytäsalasanan kopioimista sovellukseen vain siksi, että se sai yhden kertaluonteisen pyynnön onnistumaan. Määritä tili, jota sovelluksen on tarkoitus käyttää, ja pidä sitten tämä omistajuus näkyvissä käyttöönoton tietueessa.