|Autenticazione proxy integrata: account di servizio e rappresentazione

“Usa le mie credenziali Windows” ha bisogno di un soggetto. In un programma desktop può essere la persona che lo esegue. In un servizio può essere l'account del servizio. In un'applicazione Web, l'accesso riuscito di un visitatore non sostituisce automaticamente il contesto di sicurezza della richiesta in uscita.

Questo spiega perché un browser e il codice lato server sulla stessa macchina possono ottenere risultati diversi da un proxy con autenticazione integrata. Potrebbero presentare identità diverse.

Nominate le identità prima di modificare il codice

• La persona che ha eseguito l'accesso nel browser desktop.
• L'account che ospita il processo dell'applicazione.
• Qualsiasi identità rappresentata attiva per l'operazione in uscita.
• L'account che il proxy ha effettivamente accettato o rifiutato.

Sui percorsi di autenticazione integrata supportati da .NET, DefaultCredentials riguarda il contesto di sicurezza corrente. Non è un alias globale per chiunque abbia aperto una pagina su un'altra macchina.

Se il prodotto agisce deliberatamente come utente, la rappresentazione e gli eventuali requisiti di delega di rete necessitano di un proprio progetto supportato. Attivare un interruttore generico di uso delle credenziali predefinite non istituisce quel progetto. Al contrario, un'attività in background pensata per essere eseguita come identità di servizio non dovrebbe dipendere dall'apertura preliminare di un browser da parte di qualcuno.

Confrontate l'avvio interattivo e quello distribuito dopo aver rimosso i segreti: contesto dell'account, endpoint del proxy, metodo annunciato e identità rifiutata. Evitate di copiare una password desktop nell'applicazione solo perché ha fatto riuscire una richiesta isolata. Configurate l'account che l'applicazione deve usare, poi mantenete quella titolarità visibile nel registro di distribuzione.