Tienes razón al preocuparte por crear una nueva cuenta de usuario solo para esta tarea. Un enfoque mucho más sencillo es utilizar una clave de aplicación insertada en el encabezado de la solicitud. Ya que está utilizando certificados autofirmados, esto me lleva a creer que esta es una solución única y no se escalará a cientos de clientes. Aquí están los pasos para que esto suceda.
ACTUALIZACIÓN: esta solución alternativa no tendrá ningún impacto en la aplicación alojada en IIS, ya que URL Rewrite procesará la solicitud antes de la aplicación. Para eliminar inmediatamente los intentos fallidos, actualice la sección acción de la regla de Reescritura de URL a lo siguiente. Tenga en cuenta que esto hará que las solicitudes fallidas no aparezcan en los registros de IIS.
<action type="AbortRequest" />
Instalar la reescritura de URL en IIS
Este es un módulo de Microsoft que no está instalado de forma predeterminada y proporciona una funcionalidad similar a mod_rewrite.
enlace
Crear regla de reescritura de URL
Agregue la siguiente regla a web.config para su aplicación. Buscará un encabezado de solicitud de AppAuthKey (que puede cambiar / personalizar) y un valor de joshua (no distingue entre mayúsculas y minúsculas y debería ser algo más complejo). Si alguno de los dos no está presente, se devolverá el 401.4.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Application-Request-Header-Filter" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" />
<conditions>
<add input="{HTTP_AppAuthKey}" pattern="joshua" negate="true" />
</conditions>
<action type="CustomResponse" statusCode="401" subStatusCode="4" statusReason="Access denied." statusDescription="Authorization failed by filter." />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Editar comando de rizo
Actualice su comando de curvatura para incluir el encabezado de solicitud de la siguiente manera:
curl -H "AppAuthKey: joshua"
No es necesario un certificado de cliente
El uso de este método no requiere un certificado de cliente. SSL normal (debería ser TLS1.2) será suficiente siempre que esté usando cifrados fuertes. Puede encontrar más información sobre esto en la siguiente página de OWASP:
enlace
ACTUALIZACIÓN # 2
@AlphaD presenta buenos puntos con respecto a varias configuraciones de políticas que se pueden usar para limitar aún más las cuentas. Recomendaría en contra de esto ya que va en contra de la administración de la configuración. Tomar ese enfoque introduce los requisitos de configuración para el sistema que aloja la aplicación web que puede o no afectar a otros servicios. El método preferido es diseñar la aplicación web para la portabilidad, ya que se requiere muy poco del sistema de alojamiento. Supongamos que tiene sentido resaltar algunos puntos clave de por qué es preferible usar una clave de aplicación en este caso en lugar de una cuenta de usuario local o de dominio en IIS.
Usuario local
Si el usuario es local solo para el servidor web que aloja IIS, esa cuenta podrá autenticarse en cualquier otro sitio web y / o servicio alojado en ese servidor. Asegúrese de que se revisen los permisos de todos los demás recursos porque, de forma predeterminada, la cuenta será miembro del grupo local de "Usuarios", que tiene una amplitud sorprendentemente amplia. Además, esta cuenta tiene acceso de lectura en el sistema de archivos (NTFS). Si otro sitio web está mal configurado, este usuario podría ser usado para autenticar y leer su contenido. La autenticación a través de esta cuenta probablemente utilizará la autenticación básica, lo que significa que las credenciales están codificadas en Base64 (no encriptadas) y se colocan en cada encabezado de solicitud. (Al igual que mi recomendación de agregar un encabezado de solicitud personalizado para la autenticación). Finalmente, el uso de cuentas de usuarios locales dificulta la administración del sistema. Al migrar el sitio web a un nuevo servidor, se debe crear una nueva cuenta con permisos actualizados y con el alcance adecuado. Esa información de inicio de sesión debe actualizarse en el (los) script (s) de curl consumidor. No hace que tu aplicación sea portátil.
Usuario de dominio
Igual que el usuario local, ahora el alcance de donde este usuario puede autenticarse se ha expandido a todo el dominio. Esto incluye acceso de lectura a gran parte del directorio activo y otros servicios anunciados en el entorno. La autenticación con este usuario será un poco más segura ya que NTLM o Kerberos se pueden usar siempre que se pueda acceder a AD y su host de Linux esté configurado para la autenticación de AD. De lo contrario, probablemente se utilizará la Autenticación básica. La administración de cuentas se vuelve un poco más fácil ya que caerá en el ámbito de la administración de cuentas de dominio en lugar de la administración de cuentas del sistema y a menudo (no siempre) existen procedimientos bien establecidos para la administración de cuentas de dominio.
Clave de aplicación
Método preferido ya que no se requiere una cuenta de usuario y limita el alcance solo a esta aplicación. Haciendo del punto débil el canal de comunicación (asegurado a través de TLS y cifrados fuertes) y el directorio de contenido que debería tener acceso limitado de todos modos.