|Authentification proxy intégrée : comptes de service et emprunt d'identité

« Utiliser mes informations d'identification Windows » a besoin d'un sujet. Dans un programme de bureau, il peut s'agir de la personne qui l'exécute. Dans un service, il peut s'agir du compte du service. Dans une application web, la connexion réussie d'un visiteur ne remplace pas automatiquement le contexte de sécurité de la requête sortante.

Cela explique pourquoi un navigateur et du code côté serveur sur la même machine peuvent obtenir des résultats différents d'un proxy à authentification intégrée. Ils présentent peut-être des identités différentes.

Nommez les identités avant de modifier le code

• La personne connectée au navigateur de bureau.
• Le compte qui héberge le processus de l'application.
• Toute identité empruntée active pour l'opération sortante.
• Le compte que le proxy a réellement accepté ou refusé.

Sur les chemins d'authentification intégrée pris en charge par .NET, DefaultCredentials concerne le contexte de sécurité actuel. Ce n'est pas un alias global pour quiconque a ouvert une page sur une autre machine.

Si le produit agit délibérément en tant qu'utilisateur, l'emprunt d'identité et les éventuelles exigences de délégation réseau nécessitent leur propre conception prise en charge. Activer un commutateur générique d'utilisation des informations d'identification par défaut n'établit pas cette conception. À l'inverse, une tâche en arrière-plan destinée à s'exécuter sous une identité de service ne devrait pas dépendre de l'ouverture préalable d'un navigateur par quelqu'un.

Comparez le lancement interactif et le lancement déployé après avoir retiré les secrets : contexte du compte, point de terminaison du proxy, méthode annoncée et identité refusée. Évitez de copier un mot de passe de bureau dans l'application simplement parce qu'il a fait réussir une requête ponctuelle. Configurez le compte que l'application est censée utiliser, puis gardez cette propriété visible dans le registre de déploiement.