Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

520
Views
ASP.Net Core 3.1 WebClient para usar la credencial del grupo de aplicaciones para acceder a otra API que tiene autenticación de Windows

Estoy desarrollando una API utilizando el tiempo de ejecución de C# ASP.Net Core y planeo alojarla en IIS.

Uno de los requisitos es obtener información de otro servidor API RESTful que actualmente tenga autenticación de Windows (autenticación LDAP).

Ya tengo una solución usando una cuenta de servicio que codifica el nombre y la contraseña de la cuenta de servicio en appsettings.json.

El código es el siguiente

 var serviceApi = _config["Api:ServiceApi"].ToString(); // this is the URL of other RESTful API from appsettings.json var serviceAccount = _config["ServiceAccount:UserName"].ToString(); // service account username from appsettings.json var serviceAccountPwd = _config["ServiceAccount:Password"].ToString(); // service account password which is currently shown as clear text in appsettings.json var serviceAccountDomain = _config["ServiceAccount:Domain"].ToString(); // service account domain name from appsettings.json var client = new WebClient(); CredentialCache cc = new CredentialCache(); cc.Add( new Uri(serviceApi), "NTLM", new NetworkCredential(serviceAccount, serviceAccountPwd, serviceAccountDomain)); client.Credentials = cc; client.Headers["Content-Type"] = "application/json"; string response = client.DownloadString($"{serviceApi}/User");

La desventaja de esta solución es que la contraseña de la cuenta de servicio está visible en appsettings.json. Necesito otra solución que no exponga la contraseña en texto sin cifrar.

Una de las soluciones que se me ocurre es almacenar la información de la cuenta de servicio en la identidad del grupo de aplicaciones de IIS. Sin embargo, todavía no puedo hacer que WebClient use la identidad del grupo de aplicaciones de IIS. Lo que puedo hacer hasta ahora para que WebClient use mi propia credencial NTLM desde Windows.

aquí está el código

 var serviceApi = _config["Api:ServiceApi"].ToString(); var client = new WebClient(); client.UseDefaultCredentials = true; // this is not getting credential from IIS app pool identity but rather from logged in account in windows operating system client.Headers["Content-Type"] = "application/json"; string response = client.DownloadString($"{serviceApi}/User");

¿Podría ayudarme a usar la identidad del grupo de aplicaciones de IIS como credencial para otra aplicación de API RESTful?

over 4 years ago · Santiago Trujillo
2 answers
Answer question

0

En última instancia, descubrimos que no podíamos lograr esto, ya que técnicamente compromete la seguridad del usuario que inició sesión a menos que habilite la autenticación de Windows/NTLM en el servidor API (y esto requiere que el navegador/cliente habilite activamente compartir las credenciales de Windows del usuario con el servidor).

La solución que terminamos usando fue usar un secreto previamente compartido, en forma de AppId y AppSecret, que parece ser el enfoque estándar. Esencialmente, emitimos a la aplicación de llamada un nombre de usuario y una contraseña que existen fuera de AD.

over 4 years ago · Santiago Trujillo Report

0

Parece que tiene algún malentendido acerca de la autenticación de Windows.

  1. La autenticación integrada de Windows NO es autenticación LDAP.
  2. LDAP es un protocolo de conexión para consultar datos, similar a SQL, y vive en el mismo nivel en el modelo OSI que HTTP.
  3. WIA está diseñado para nunca permitir que la contraseña del usuario abandone el navegador cuando se usa en HTTP (sin embargo, NTLM es un poco inseguro ya que se sabe que el hash de LM está roto).

Entonces, dado todo lo anterior. Desea utilizar Windows Integrated Security con Kerberos SPNEGO entre su servidor web frontend y el servidor web backend.

La siguiente será una breve guía de solución de problemas.

  • El servidor backend identifica mi servicio como [MachineName]. Esto se debe a que está utilizando una cuenta que no es de AD para ejecutar su aplicación. Utilice el alojamiento de InProcess y cree un nuevo grupo de aplicaciones con una cuenta de servicio de AD para ejecutar la aplicación.
  • El servidor backend identifica mi servicio como [usuario del navegador web]. Es muy poco probable que esto haya sucedido por accidente en un entorno de producción. Para que esto ocurra, cuando el navegador, el frontend y el backend están en diferentes PC, debe significar que activó accidentalmente la autenticación de Windows, la suplantación de identidad de Windows, la autenticación Kerberos y configuró SPN para la delegación entre el frontend y el backend. Todo sin cometer un error. He pasado meses de mi vida tratando de hacer esto a propósito.
  • Los poderes fácticos ordenaron que deshabilitáramos la autenticación NTLM y Kerberos no funciona. Lo más probable es que su problema sea configurar SPN en su AD para que la dirección http apunte a su Identidad de AppPool (que nuevamente debe ser una cuenta de AD o la cuenta de la máquina).
over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!