|Integra prokura aŭtentigado: servokontoj kaj personiĝo
|Ekzamenu la sekurecan kuntekston malantaŭ integra prokura aŭtentigado kiam la sama aplikaĵo funkcias interage kaj fiaskas kiel retservo aŭ planita procezo.
“Uzi miajn Windows-akreditaĵojn” bezonas subjekton. En surtabla programo tio povas esti la persono, kiu ĝin ruligas. En servo tio povas esti la konto de la servo. En reta aplikaĵo la sukcesa ensaluto de vizitanto ne aŭtomate anstataŭigas la sekurecan kuntekston de la elira peto.
Tio klarigas, kial retumilo kaj servila kodo sur la sama maŝino povas ricevi malsamajn rezultojn de prokuro kun integra aŭtentigado. Ili eble prezentas malsamajn identecojn.
Nomu la identecojn antaŭ ol ŝanĝi la kodon
- La persono ensalutinta en la surtabla retumilo.
- La konto, kiu gastigas la aplikaĵan procezon.
- Ajna personigita identeco aktiva por la elira operacio.
- La konto, kiun la prokuro efektive akceptis aŭ malakceptis.
Sur la subtenataj vojoj de integra aŭtentigado de .NET, DefaultCredentials koncernas la nunan sekurecan kuntekston. Ĝi ne estas tutmonda kaŝnomo por ĉiu, kiu malfermis paĝon sur alia maŝino.
Se la produkto intence agas kiel uzanto, personiĝo kaj eventualaj postuloj pri reta delegado bezonas propran subtenatan dezajnon. Ŝalti ĝeneralan ŝaltilon por uzi defaŭltajn akreditaĵojn ne starigas tiun dezajnon. Male, fona tasko destinita por ruliĝi kiel serva identeco ne devus dependi de tio, ke iu unue malfermas retumilon.
Komparu la interagan kaj la dislokitan lanĉojn kun sekretoj forigitaj: konta kunteksto, prokura finpunkto, anoncita metodo kaj malakceptita identeco. Evitu kopii surtablan pasvorton en la aplikaĵon nur ĉar ĝi igis unufojan peton sukcesi. Agordu la konton, kiun la aplikaĵo devas uzi, kaj poste tenu tiun posedon videbla en la dislokiga registro.