|Yntegrearre proxy-autentikaasje: tsjinstakkounten en ymplantaasje
|Undersykje de befeiligingskontekst efter yntegrearre proxy-autentikaasje as deselde applikasjon ynteraktyf wurket en as webservice of plend proses mislearret.
“Myn Windows-beynskippen brûke” hat in subjekt nedich. Yn in buroblêdprogramma kin dat de persoan wêze dy't it útfiert. Yn in tsjinst kin dat it akkount fan de tsjinst wêze. Yn in webapplikaasje ferfangt de slagge oanmelding fan in besiker net automatysk de befeiligingskontekst fan it útgeande fersyk.
Dat ferklearret wêrom't in browser en tsjinner-side koade op deselde masine ferskillende resultaten fan in proxy mei yntegrearre autentikaasje krije kinne. Se litte miskien ferskillende identiteiten sjen.
Nammje de identiteiten foardat jo de koade feroarje
- De persoan dy't oanmeld is yn 'e buroblêdbrowser.
- It akkount dat it applikaasjeproses host.
- Elke ymplante identiteit dy't aktyf is foar de útgeande operaasje.
- It akkount dat de proxy eins akseptearre of wegere.
Op de stipe paden fan .NET foar yntegrearre autentikaasje giet DefaultCredentials oer de hjoeddeiske befeiligingskontekst. It is gjin algemien alias foar elkenien dy't in side op in oare masine iepene hat.
As it produkt bewust as brûker hannelet, hawwe ymplantaasje en alle easken foar netwurkdelegaasje har eigen stipe ûntwerp nedich. It oansette fan in algemiene skeakel foar it brûken fan standertbeynskippen fêstiget dat ûntwerp net. Oarsom soe in beneftergrûnopdracht dy't as tsjinstidentiteit rinne moat, net ôfhinklik wêze moatte fan dat immen earst in browser iepenet.
Fergelykje de ynteraktive en de útrôle lansearring sûnder geheimen: akkountkontekst, proxy-einpunt, oankundige metoade en wegere identiteit. Foarkom dat jo in buroblêdwachtwurd yn 'e applikaasje kopiearje, allinne om't it ien ienmalige fersyk slagje liet. Konfigurearje it akkount dat de applikaasje brûke moat, en hâld dan dat eigendom sichtber yn 'e útrôlregistraasje.