Estoy trabajando en un conjunto de aplicaciones que requieren autenticación y autorización.
¿Puede indicarme la dirección correcta hacia el diseño de arquitectura para esto cuando quiero tener múltiples servicios en ejecución y cómo administrar exactamente la autenticación de servicio a servicio y la autenticación de usuario a servicio también?
Probablemente haré todo esto a través de OAuth2, etc., pero no estoy seguro de cuál es la forma correcta de implementar esto.
Esperemos que esto ayude.
Sistemas de gestión de identidad
El sistema de administración de identidades a menudo se define por fuentes confiables. Estos son los sistemas en los que confiamos para una fuente de registro para un individuo. No son realmente una sola pieza. Compre una combinación de diseño de sistemas para administrar personas.
Fuente de confianza de datos de identidad
Estos son datos de personas, que normalmente se encuentran en sus sistemas de recursos humanos. Son muy variados y pueden ser tan simples como AD para una organización pequeña.
Autorización / autenticación de origen confiable
Este es un sistema o sistemas que su organización usa para AAA. En muchas organizaciones, eso es solo el Directorio Activo de MicroSoft, sin embargo, existen varios servicios basados en directorios y las organizaciones más grandes pueden tener sistemas divididos en diferentes fuentes.
Inicio de sesión único
La mayoría de las organizaciones que usan SSO dentro de la organización probablemente usan algún tipo de Servicio de Identidad Federada que permite tener una única identificación en múltiples sistemas AAA.
Los servicios federados modernos permiten las comunicaciones SAML y OAuth 2.0. Si desea ser técnico, OAuth no está dirigido a la autenticación, es la autorización. Proporciona un mecanismo para el intercambio de autenticación, pero eso no es su intención.
SAML está activado para ambos, y es típico de los servicios Enterprise SSO.
Si se trata de aplicaciones personalizadas, un estándar que he agregado a mi trabajo de desarrollo es JWT (JSON Web Tokens), que no es realmente SSO per-say, sino más bien un mecanismo para habilitar las funciones SSO en aplicaciones modernas, pero puede Manejar tanto la autenticación como la autorización.
Ejemplos de sistemas IDM comunes
Yo trabajo con estos dos sistemas. Tengo muchas reservas sobre ellos. Sailpoint es más moderno, Oracle está bien Oracle (un montón de ups / LOTS de downs). Siempre creo que podría construir una mejor (que podría intentar un día para divertirme).
Hazlo tú mismo las configuraciones
Comprenda que IDM / IAM / IdAM (o lo que sea que desee) está diseñado para proporcionar un conjunto común de funciones administrativas relacionadas con las personas y el acceso a los recursos. Esto incluye ser un repositorio central para identificar acceso, administración de roles, implementación de políticas y aprovisionamiento / desaprovisionamiento de recursos. Wiki para referencia.
Su objetivo real suena menos como IDM y más como administración de recursos, es algo que no se logra específicamente con este sistema. Pocas cosas:
Creo que es posible que desee comenzar con los servicios federados e investigarlos. Esto le dará una comprensión de cuál es su propósito. La mayoría de las organizaciones que buscan un SSO a escala, buscan servicios federados para simplificar las cosas.
Aquí es donde el término tienda MicroSoft entra en juego, por lo que se menciona porque todas sus aplicaciones son MS y se pueden autenticar en AD. Nunca he estado en una organización que tuviera esto pero, Kudos si tienes esa simplicidad.
General recomendaciones para implementación :
Generalmente, OpenID Connect y OAuth2 se utilizan para fines de SSO:
Autorización es más difícil de dar recomendaciones generales, ya que generalmente depende de la lógica empresarial. Además, no hay buenos estándares en esa área (XACML parece complejo para la mayoría de los casos y no es adecuado para la pila JSON + REST). En casos simples, los ámbitos OAuth2 son suficientes, en casos más complejos, las reglas de autorización se pueden implementar dentro de diferentes servicios por separado , pero se administran de forma centralizada (por ejemplo, el servicio registrará los roles proporcionados dentro de IDM).
Puede adquirir una suscripción de proveedores de soluciones IDaaS como OKTA, Ping, etc. Ping tiene exclusivamente un producto Ping Access para OAuth2.0. La implementación se guiará por el proveedor de soluciones IDaaS mediante el estudio de la arquitectura.
Lea otras preguntas en las etiquetas authentication oauth user-management access-control identity