Tengo una aplicación web (alojada en IIS) que habla con un servicio de Windows. El servicio de Windows está utilizando la API web ASP.Net MVC (autohospedado), por lo que se puede comunicar a través de http utilizando JSON. La aplicación web está configurada para suplantar, la idea es que el usuario que realiza la solicitud a la aplicación web debe ser el usuario que la aplicación web utiliza para realizar la solicitud al servicio. La estructura se ve así:

_{(El usuario resaltado en rojo es el usuario al que se hace referencia en los ejemplos a continuación).}

La aplicación web realiza solicitudes al servicio de Windows utilizando un HttpClient:

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

Esto realiza la solicitud al servicio de Windows, pero no pasa las credenciales correctamente (el servicio informa al usuario como IIS APPPOOL\ASP.NET 4.0). Esto no es lo que quiero que suceda .

Si cambio el código anterior para usar un WebClienten su lugar, las credenciales del usuario se pasan correctamente:

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

Con el código anterior, el servicio informa al usuario como el usuario que realizó la solicitud a la aplicación web.

¿Qué estoy haciendo mal con la HttpClientimplementación que hace que no pase las credenciales correctamente (o es un error con el HttpClient)?

_{La razón por la que quiero usar HttpClientes que tiene una API asíncrona que funciona bien con Tasks, mientras que la WebClientAPI asíncrona debe manejarse con eventos.}

También estaba teniendo este mismo problema. Desarrollé una solución síncrona gracias a la investigación realizada por @tpeczek en el siguiente artículo de SO: No se puede autenticar al servicio ASP.NET Web Api con HttpClient

Mi solución utiliza un WebClient, que como notó correctamente, pasa las credenciales sin problemas. La razón por la HttpClientque no funciona es porque la seguridad de Windows deshabilita la capacidad de crear nuevos subprocesos bajo una cuenta suplantada (consulte el artículo SO anterior). HttpClientCrea nuevos subprocesos a través de la Fábrica de tareas, lo que causa el error. WebClientpor otro lado, se ejecuta sincrónicamente en el mismo hilo, evitando así la regla y reenviando sus credenciales.

Aunque el código funciona, la desventaja es que no funcionará de forma asíncrona.

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();
}

Nota: Requiere el paquete NuGet: Newtonsoft.Json, que es el mismo serializador JSON que utiliza WebAPI.

Puede configurar HttpClientpara pasar automáticamente credenciales como esta:

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

Lo que está tratando de hacer es hacer que NTLM reenvíe la identidad al siguiente servidor, lo que no puede hacer: solo puede suplantar lo que solo le da acceso a los recursos locales. No te permitirá cruzar el límite de una máquina. La autenticación Kerberos admite la delegación (lo que necesita) mediante el uso de tickets, y el ticket se puede reenviar cuando todos los servidores y aplicaciones de la cadena están configurados correctamente y Kerberos está configurado correctamente en el dominio. Entonces, en resumen, debe cambiar el uso de NTLM a Kerberos.

Para obtener más información sobre las opciones de autenticación de Windows disponibles y cómo funcionan, comience en: http://msdn.microsoft.com/en-us/library/ff647076.aspx

OK, así que gracias a todos los contribuyentes anteriores. Estoy usando .NET 4.6 y también tuvimos el mismo problema. Pasé tiempo depurando System.Net.Http, específicamente el HttpClientHandler, y encontré lo siguiente:

    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);
    }

Entonces, después de evaluar que el ExecutionContext.IsFlowSuppressed()culpable podría haber sido el culpable, envolví nuestro código de suplantación de la siguiente manera:

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

El código dentro de SafeCaptureIdenity(no es mi error de ortografía), agarra WindowsIdentity.Current()cuál es nuestra identidad suplantada. Esto se está recogiendo porque ahora estamos suprimiendo el flujo. Debido al uso / disposición, esto se restablece después de la invocación.

Ahora parece funcionar para nosotros, ¡uf!

En .NET Core, logré obtener una System.Net.Http.HttpClientcon UseDefaultCredentials = truepara pasar las credenciales de Windows del usuario autenticado a un servicio de fondo mediante el uso 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);
    });
}

Me funcionó después de configurar un usuario con acceso a Internet en el servicio de Windows.

En mi código:

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

Ok, tomé el código de Joshoun y lo hice genérico. No estoy seguro de si debería implementar el patrón singleton en la clase SynchronousPost. Quizás alguien más conocedor pueda ayudar.

Implementación

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

Clase genérica aquí. Puedes pasar cualquier tipo

 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; }
    }

Mis clases de Api se ven así, si tienes curiosidad

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();
    }
}

Estoy usando ninject y repo pattern con unidad de trabajo. De todos modos, la clase genérica anterior realmente ayuda.