J'ai une application Web (hébergée dans IIS) qui communique avec un service Windows. Le service Windows utilise l'API Web ASP.Net MVC (auto-hébergée) et peut donc être communiqué via http à l'aide de JSON. L'application Web est configurée pour effectuer une usurpation d'identité, l'idée étant que l'utilisateur qui fait la demande à l'application Web doit être l'utilisateur que l'application Web utilise pour faire la demande au service. La structure ressemble à ceci:

_{(L'utilisateur surligné en rouge est l'utilisateur auquel il est fait référence dans les exemples ci-dessous.)}

L'application Web envoie des demandes au service Windows à l'aide d'un HttpClient:

var httpClient = new HttpClient(new HttpClientHandler() 
                      {
                          UseDefaultCredentials = true
                      });
httpClient.GetStringAsync("http://localhost/some/endpoint/");

Cela fait la demande au service Windows, mais ne transmet pas correctement les informations d'identification (le service signale l'utilisateur comme IIS APPPOOL\ASP.NET 4.0). Ce n'est pas ce que je souhaite .

Si je change le code ci-dessus pour utiliser à la WebClientplace, les informations d'identification de l'utilisateur sont transmises correctement:

WebClient c = new WebClient
                   {
                       UseDefaultCredentials = true
                   };
c.DownloadStringAsync(new Uri("http://localhost/some/endpoint/"));

Avec le code ci-dessus, le service signale l'utilisateur comme l'utilisateur qui a fait la demande à l'application Web.

Qu'est-ce que je fais mal avec l' HttpClientimplémentation qui fait qu'elle ne transmet pas correctement les informations d'identification (ou est-ce un bogue avec le HttpClient)?

_{La raison pour laquelle je veux utiliser l ' HttpClientest qu'il a une API asynchrone qui fonctionne bien avec Tasks, alors que l WebClient' API asyc doit être gérée avec des événements.}

J'avais aussi ce même problème. J'ai développé une solution synchrone grâce à la recherche effectuée par @tpeczek dans l'article SO suivant: Impossible de s'authentifier auprès du service Web Api ASP.NET avec HttpClient

Ma solution utilise un WebClient, qui, comme vous l'avez correctement noté, transmet les informations d'identification sans problème. La raison HttpClientne fonctionne pas parce que la sécurité Windows désactive la possibilité de créer de nouveaux threads sous un compte usurpé (voir l'article SO ci-dessus.) HttpClientCrée de nouveaux threads via Task Factory, provoquant ainsi l'erreur. WebClientd'autre part, s'exécute de manière synchrone sur le même thread, contournant ainsi la règle et transmettant ses informations d'identification.

Bien que le code fonctionne, l'inconvénient est qu'il ne fonctionnera pas de manière asynchrone.

var wi = (System.Security.Principal.WindowsIdentity)HttpContext.Current.User.Identity;

var wic = wi.Impersonate();
try
{
    var data = JsonConvert.SerializeObject(new
    {
        Property1 = 1,
        Property2 = "blah"
    });

    using (var client = new WebClient { UseDefaultCredentials = true })
    {
        client.Headers.Add(HttpRequestHeader.ContentType, "application/json; charset=utf-8");
        client.UploadData("http://url/api/controller", "POST", Encoding.UTF8.GetBytes(data));
    }
}
catch (Exception exc)
{
    // handle exception
}
finally
{
    wic.Undo();
}

Remarque: nécessite le package NuGet: Newtonsoft.Json, qui est le même que le sérialiseur JSON que WebAPI utilise.

Vous pouvez configurer HttpClientpour transmettre automatiquement les informations d'identification comme ceci:

var myClient = new HttpClient(new HttpClientHandler() { UseDefaultCredentials = true });

Ce que vous essayez de faire, c'est demander à NTLM de transmettre l'identité au serveur suivant, ce qu'il ne peut pas faire - il ne peut faire que l'emprunt d'identité qui vous donne uniquement accès aux ressources locales. Cela ne vous permettra pas de franchir les limites d'une machine. L'authentification Kerberos prend en charge la délégation (dont vous avez besoin) à l'aide de tickets, et le ticket peut être transféré lorsque tous les serveurs et applications de la chaîne sont correctement configurés et que Kerberos est correctement configuré sur le domaine. Donc, en bref, vous devez passer de NTLM à Kerberos.

Pour en savoir plus sur les options d'authentification Windows disponibles et leur fonctionnement, accédez à: http://msdn.microsoft.com/en-us/library/ff647076.aspx

OK, merci à tous les contributeurs ci-dessus. J'utilise .NET 4.6 et nous avons également eu le même problème. J'ai passé du temps à déboguer System.Net.Http, en particulier le HttpClientHandler, et j'ai trouvé ce qui suit:

    if (ExecutionContext.IsFlowSuppressed())
    {
      IWebProxy webProxy = (IWebProxy) null;
      if (this.useProxy)
        webProxy = this.proxy ?? WebRequest.DefaultWebProxy;
      if (this.UseDefaultCredentials || this.Credentials != null || webProxy != null && webProxy.Credentials != null)
        this.SafeCaptureIdenity(state);
    }

Donc, après avoir évalué que cela ExecutionContext.IsFlowSuppressed()aurait pu être le coupable, j'ai enveloppé notre code d'usurpation d'identité comme suit:

using (((WindowsIdentity)ExecutionContext.Current.Identity).Impersonate())
using (System.Threading.ExecutionContext.SuppressFlow())
{
    // HttpClient code goes here!
}

Le code à l'intérieur de SafeCaptureIdenity(pas ma faute d'orthographe), saisit WindowsIdentity.Current()qui est notre identité usurpée. Cela est repris parce que nous supprimons maintenant le flux. En raison de l'utilisation / de l'élimination, ceci est réinitialisé après l'appel.

Cela semble maintenant fonctionner pour nous, ouf!

Dans .NET Core, j'ai réussi à obtenir un System.Net.Http.HttpClientwith UseDefaultCredentials = truepour transmettre les informations d'identification Windows de l'utilisateur authentifié à un service principal en utilisant WindowsIdentity.RunImpersonated.

HttpClient client = new HttpClient(new HttpClientHandler { UseDefaultCredentials = true } );
HttpResponseMessage response = null;

if (identity is WindowsIdentity windowsIdentity)
{
    await WindowsIdentity.RunImpersonated(windowsIdentity.AccessToken, async () =>
    {
        var request = new HttpRequestMessage(HttpMethod.Get, url)
        response = await client.SendAsync(request);
    });
}

Cela a fonctionné pour moi après avoir configuré un utilisateur avec un accès Internet dans le service Windows.

Dans mon code:

HttpClientHandler handler = new HttpClientHandler();
handler.Proxy = System.Net.WebRequest.DefaultWebProxy;
handler.Proxy.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;
.....
HttpClient httpClient = new HttpClient(handler)
.... 

Ok donc j'ai pris le code Joshoun et l'ai rendu générique. Je ne suis pas sûr de devoir implémenter le modèle singleton sur la classe SynchronousPost. Peut-être que quelqu'un de plus compétent peut vous aider.

la mise en oeuvre

FileCategory x = new FileCategory { CategoryName = "Some Bs"};
SynchronousPost<FileCategory>test= new SynchronousPost<FileCategory>();
test.PostEntity(x, "/api/ApiFileCategories"); 

Classe générique ici. Vous pouvez passer n'importe quel type

 public class SynchronousPost<T>where T :class
    {
        public SynchronousPost()
        {
            Client = new WebClient { UseDefaultCredentials = true };
        }

        public void PostEntity(T PostThis,string ApiControllerName)//The ApiController name should be "/api/MyName/"
        {
            //this just determines the root url. 
            Client.BaseAddress = string.Format(
         (
            System.Web.HttpContext.Current.Request.Url.Port != 80) ? "{0}://{1}:{2}" : "{0}://{1}",
            System.Web.HttpContext.Current.Request.Url.Scheme,
            System.Web.HttpContext.Current.Request.Url.Host,
            System.Web.HttpContext.Current.Request.Url.Port
           );
            Client.Headers.Add(HttpRequestHeader.ContentType, "application/json;charset=utf-8");
            Client.UploadData(
                                 ApiControllerName, "Post", 
                                 Encoding.UTF8.GetBytes
                                 (
                                    JsonConvert.SerializeObject(PostThis)
                                 )
                             );  
        }
        private WebClient Client  { get; set; }
    }

Mes classes d'API ressemblent à ceci, si vous êtes curieux

public class ApiFileCategoriesController : ApiBaseController
{
    public ApiFileCategoriesController(IMshIntranetUnitOfWork unitOfWork)
    {
        UnitOfWork = unitOfWork;
    }

    public IEnumerable<FileCategory> GetFiles()
    {
        return UnitOfWork.FileCategories.GetAll().OrderBy(x=>x.CategoryName);
    }
    public FileCategory GetFile(int id)
    {
        return UnitOfWork.FileCategories.GetById(id);
    }
    //Post api/ApileFileCategories

    public HttpResponseMessage Post(FileCategory fileCategory)
    {
        UnitOfWork.FileCategories.Add(fileCategory);
        UnitOfWork.Commit(); 
        return new HttpResponseMessage();
    }
}

J'utilise ninject et repo pattern avec unité de travail. Quoi qu'il en soit, la classe générique ci-dessus aide vraiment.