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 :
- 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.
- On fait donc un « revert-to-self » : le thread continue son excécution sous l'identité du process (ie de l'application pool)
- On exécute la requête vers le back-end
- 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 =-