Solution du « revert-to-self » pour les problèmes de « double-hop »

Dans un précédent post (voir cet article), nous évoquions différentes méthodes pour pallier le problème de double saut. Je vous porpose de détailler ici la méthode #3 :

Faire un revert-to-self (par code) pour forcer le thread à utiliser l’identité du process : toutes les connexions au back-end se feront alors sous cette même identité.

Cette méthode est applicable dans une application ASP.NET en mode impersonate=true. Le scénario est alors le suivant :

  1. L'utilisateur se connecte à l'application Web. Il s'authentifie en Windows auprès de IIS qui passe le jeton à ASP.NET. ASP.NET lance exécute alors le thread pour le traitement de la requête sous l'identité de l'utilisateur. C'est là quele porblème de double-hop peut survenir en cas de connexion à un système back-end : ASP.NET ne peut pas réutiliser l'identité de l'utilisateur initial.
  2. On fait donc un « revert-to-self » : le thread continue son excécution sous l'identité du process (ie de l'application pool)
  3. On exécute la requête vers le back-end
  4. On revient à l'identité initiale du thread (ie celle de l'utilisateur) pour la suite de l'exécution de la requête

Pour réaliser le « revert-to-self », on utilise un appel à la méthode suivante : 

using

System.Security.Principal;

. . .

WindowsIdentity wi = null; // pour stocker l'identité afin d'y revenir plus tard

// Stocke l'identité courante et revient à l'identité du process
private void BackToProcessID()
{
wi = WindowsIdentity.GetCurrent();
WindowsIdentity.Impersonate(IntPtr.Zero);
}
 

Pour revenir à l'identité de l'utilisateur, on appelera cette méthode :

// Revient à l'identité stockée
private void BackToUserID()
{
if(wi != null)
wi.Impersonate();
}

-= Julien Bakmezdjian =-