|Geïntegreerde proxyverificatie: serviceaccounts en imitatie

“Mijn Windows-referenties gebruiken” heeft een subject nodig. In een desktopprogramma kan dat de persoon zijn die het uitvoert. In een service kan dat het account van de service zijn. In een webtoepassing vervangt de geslaagde aanmelding van een bezoeker niet automatisch de beveiligingscontext van het uitgaande verzoek.

Dit verklaart waarom een browser en server-side code op dezelfde machine verschillende resultaten kunnen krijgen van een proxy met geïntegreerde verificatie. Ze presenteren mogelijk verschillende identiteiten.

Benoem de identiteiten voordat je de code wijzigt

• De persoon die is aangemeld bij de desktopbrowser.
• Het account dat het toepassingsproces host.
• Elke geïmiteerde identiteit die actief is voor de uitgaande bewerking.
• Het account dat de proxy daadwerkelijk heeft geaccepteerd of geweigerd.

Op de door .NET ondersteunde paden voor geïntegreerde verificatie betreft DefaultCredentials de huidige beveiligingscontext. Het is geen globale alias voor iedereen die een pagina op een andere machine heeft geopend.

Als het product bewust als gebruiker optreedt, hebben imitatie en eventuele vereisten voor netwerkdelegatie hun eigen ondersteunde ontwerp nodig. Een algemene schakelaar voor het gebruik van standaardreferenties aanzetten vestigt dat ontwerp niet. Omgekeerd zou een achtergrondtaak die bedoeld is om als service-identiteit te draaien niet afhankelijk moeten zijn van iemand die eerst een browser opent.

Vergelijk de interactieve en de uitgerolde start zonder geheimen: accountcontext, proxy-eindpunt, aangekondigde methode en geweigerde identiteit. Vermijd het kopiëren van een desktopwachtwoord naar de toepassing alleen omdat het ene eenmalige verzoek daardoor slaagde. Configureer het account dat de toepassing hoort te gebruiken en houd dat eigenaarschap vervolgens zichtbaar in het uitrolrecord.