AUTH_REQUIRED=true en la integración del producto cuando las solicitudes deban rechazarse si su cliente Auth no está disponible o está mal configurado.
Por debajo, dos servicios hacen el trabajo, y los productos protegidos se conectan a ellos a nivel de ruta:
- Auth ejecuta el lado en vivo del acceso: emite y refresca tokens, valida sesiones, comprueba permisos, gestiona el cierre de sesión y la información de usuario, y ejecuta los desafíos de MFA.
- Identity guarda los datos que respaldan esas decisiones: usuarios, grupos, aplicaciones, proveedores de comunicación, vínculos aplicación-proveedor y configuración de MFA.
midaz-viewer-group puede leer datos de Midaz pero no modificarlos. Una integración de servicio recibe acceso según su sujeto M2M efectivo. De forma predeterminada, los tokens que no son de usuario usan admin/<product>-editor-role; configura AUTH_M2M_INVERSION_ENABLED=true para usar el sub del token de la aplicación.
¿Por qué usar Access Manager?
Usa Access Manager cuando quieras un control de acceso nativo y detallado en todos los productos Lerian, en lugar de improvisar algo producto por producto. Te permite:
- gestionar usuarios humanos y los grupos de producto que definen su acceso;
- crear aplicaciones máquina a máquina para integraciones de servicio;
- aplicar permisos hasta el nivel de recurso y acción, como
reports:get,templates:postoaccounts:patch; - aplicar un único modelo de control de acceso en cada producto Lerian que ejecutes;
- mantener las APIs de los productos protegidas detrás de bearer tokens y comprobaciones a nivel de ruta.
- En despliegues SaaS, es la capa de acceso de la plataforma. Las claims del JWT portan el sujeto autenticado y el contexto de tenant de los que depende la plataforma.
- En despliegues BYOC multi-tenant, el contexto de tenant proviene de claims de token de confianza, nunca de payloads de solicitud ni de headers arbitrarios.
- En despliegues BYOC single-tenant, es posible que ya ejecutes tu propio proveedor de identidad. Access Manager todavía puede añadir autorización nativa de Lerian y credenciales de aplicación allí donde necesites ese control.
Especificaciones técnicas
Lo que obtienes de fábrica:
- APIs REST para operaciones de Auth e Identity.
- Configuración en Lerian Console para la gestión visual de usuarios y aplicaciones admitida.
- Aplicación de autorización a nivel de producto para APIs HTTP y gRPC protegidas.
- Configuración del cliente Auth por producto para aplicar la autorización a nivel de ruta.
- Flujos de token OAuth2/OIDC para acceso por contraseña y por credenciales de cliente.
- Soporte de MFA para los flujos de autenticación de usuarios.
- Caching respaldado por Valkey para operaciones de token, permisos y MFA.
- RBAC alineado con los recursos, acciones, grupos y aplicaciones máquina a máquina de los productos.
Bootstrap y operación
Access Manager tiene dos capas de ciclo de vida distintas, y mantenerlas separadas te ahorra problemas más adelante:
El bootstrap es lo que siembra un entorno nuevo. Una vez que ese entorno está en marcha, deja de ser donde haces cambios. Para el recorrido a nivel de operador sobre cómo dejar Auth e Identity listos antes de que cualquier producto aplique acceso, consulta Instalar Access Manager.
A partir de ahí, gestiona el acceso a través de las APIs de Identity o de Lerian Console. Console cubre el trabajo cotidiano de usuarios y aplicaciones: crear usuarios, asignar grupos, actualizar contraseñas y crear aplicaciones máquina a máquina. Las APIs de Identity te dan la superficie operativa completa, incluyendo proveedores, vínculos aplicación-proveedor y MFA.
Los recursos, acciones, roles y conjuntos de permisos integrados son otra historia. Despliega cambios en ellos mediante actualizaciones controladas de la plataforma, como migraciones o un reconciliador idempotente, y no edites los datos semilla del bootstrap para cambiar el acceso en un entorno que ya está en marcha.
Comportamiento multi-tenant
En despliegues SaaS y BYOC multi-tenant, el tenant es parte de quién es quien llama, no algo que envíe. Access Manager lo lee de claims JWT de confianza durante los flujos de usuario, y de la organización de la aplicación durante los flujos máquina a máquina. Los clientes nunca envían la pertenencia de tenant en payloads, parámetros de consulta ni headers. Eso moldea el comportamiento en tres puntos:
- Gestión de identidad: las APIs de usuarios, grupos y aplicaciones devuelven solo los registros de la organización de tenant de quien llama.
- Autenticación: los flujos de contraseña y de refresh-token mantienen el manejo de tokens acotado al tenant que porta el contexto del usuario.
- Autorización: las comprobaciones de permisos evalúan solo los grupos, roles y permisos de aplicación que pertenecen al tenant resuelto.
Casos de uso
Access Manager encaja en escenarios como:
- Equipos que quieren autenticación y autorización integradas en todos los productos Lerian.
- Organizaciones sin una solución IAM preexistente.
- Equipos que ya ejecutan un proveedor de identidad pero aún necesitan autorización a nivel de producto.
- Integraciones que dependen de un acceso máquina a máquina seguro.
- Despliegues multiproducto que necesitan un único modelo de acceso consistente para usuarios, servicios y tenants.