Autenticación entre servicios web dentro del mismo proyecto

Si su sistema es relativamente pequeño y no está demasiado preocupado por los ataques de intermediarios, entonces una clave precompartida es la forma más sencilla de hacerlo. Piense en ello como una contraseña que un servidor utiliza para reconocer otro. Idealmente, cada servidor tiene su propia contraseña que se utiliza para identificarse con los demás. Si lo necesita, puede evitar revelar la contraseña y, al mismo tiempo, demostrar su conocimiento mediante el uso de una desafío-respuesta mecanismo de hash.

Si su sistema es grande o si se agregan y eliminan nodos con la frecuencia suficiente para que las claves compartidas sean difíciles de mantener, le recomiendo crear su propia PKI. Esto es lo suficientemente simple para hacer con los certificados SSL: simplemente genere un certificado de firma central y márquelo (y solo) como confiable para todos sus servidores, y emita a cada servidor / servicio su propio certificado, que se utiliza para identificarse con los demás. Utilice el campo de asunto del certificado para vincular el certificado al servidor / servicio, y por supuesto firme cada uno con su certificado de firma. SSL proporciona la autenticación mutua tanto del cliente como del servidor para una única conexión, por lo que puede usar componentes completamente disponibles para esto. Si es necesario, puede incluir tiempos de vencimiento cortos y / o usar la revocación para mejorar la seguridad si le preocupa que las llaves caigan en las manos equivocadas.

Estás haciendo dos preguntas separadas aquí.

Acceso programático. La primera pregunta es: para los servicios web que solo deben estar expuestos a otro código interno, ¿cómo deben autenticarse los clientes programáticos? Mi respuesta: recomiendo usar SSL con certificados de cliente.

Aquí es cómo hacer eso, con más detalle. El cliente debe ponerse en contacto con el servicio a través de una URL https. Cada cliente debe tener su propio certificado de cliente SSL. El servicio debe verificar que el certificado del cliente esté en una lista de clientes autorizados, o bien, verificar que el certificado del cliente esté firmado por su CA interna (su elección).

Además, para una mejor seguridad, puede considerar ejecutar esos servicios web internos en un host separado con un servidor de seguridad externo, para que nadie en la Internet externa pueda abrir una conexión a esos servicios web internos.

Acceso humano. La segunda pregunta es: para los servicios web que solo deben estar expuestos a los administradores internos del sistema, ¿cómo se debe controlar el acceso? Mi respuesta: hay varios enfoques.

La respuesta más sencilla y probablemente la más pragmática es configurar una cuenta separada para cada uno de sus administradores y usar la autenticación estándar basada en contraseña para limitar el acceso a esas cuentas. Genere una contraseña larga y segura para cada cuenta de administrador y dígale al administrador que no comparta su contraseña. Configure el servicio web para usar SSL en todo el sitio (solo se puede acceder a través de https, no a través de http), para evitar que los atacantes detecten la contraseña de un administrador si se conectan a través de una conexión Wifi abierta. En este enfoque, los servicios web todavía se ejecutan en un host conectado a Internet externo, pero nadie más que un administrador debería poder iniciar sesión en ellos.

Un enfoque más seguro es colocar esos servicios web en su red interna y no colocarlos en un host externo. Corta el firewall fuera de Internet. Si sus administradores desean iniciar sesión mientras trabajan de forma remota, pueden VPN en su red interna. Aún querrá crear una cuenta para cada administrador en el servicio web y generar contraseñas seguras y largas para los administradores.

Para instalaciones de alta seguridad, hay formas adicionales de proporcionar una seguridad aún más sólida. Es probable que esos mecanismos no sean necesarios para el servicio web interno promedio, pero si se encuentra en un área especialmente sensible a la seguridad, solo háganoslo saber y podemos proporcionarle controles adicionales.

Tu pregunta no es muy clara. Suena por una parte como si estuviera interesado en la autenticación dentro del servicio, que no es lo que supongo que está intentando resolver.

  

Lo que debemos evitar aquí es, básicamente, personas que envían al azar   consultas / publicaciones en este servicio web que solo deben ser utilizadas por   los otros.

Por lo tanto, si el objetivo es permitir solo a los usuarios que usted puede autenticar, le dirijo a su proveedor de autenticación de rieles hacia su sistema de "autenticación global". Supongo que tiene una interfaz LDAP, por lo que debería ser bastante simple configurarlo.

Su autenticación también servirá como su autorización, ya que su objetivo era solo permitir que los usuarios puedan autentificarse.

Con un token de clave aleatoria, por usuario, del lado del servidor, que es desconocido para el usuario, pero solo para los servicios web. De esta manera, obtienes cada ejecución en un contexto específico, como si le hubieras asignado un nombre de usuario. Esto se puede pasar a través de la solicitud HTTP HTTP, o en el encabezado de la cookie, o en la URL, depende de sus requisitos.

Simplemente cada sesión requeriría una autenticación previa de algún tipo y utilizar tokens en todos los servicios, por lo que no tendrá que iniciar sesión nuevamente.

Esto funciona igual que el servidor de usuario, de la misma manera que el servidor servidor, como el servidor tiene que iniciar sesión en el sitio web, y luego puede navegar por las páginas, en este caso, los servicios web.

También cuando el usuario inicia sesión, también se le puede otorgar este token, para que pueda vincular al usuario de front-end con la sesión de back-end.