> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.
# ¿Qué es Access Manager?
> Controla el acceso de personas y máquinas en los productos Lerian con Auth, Identity y aplicación de autorización a nivel de producto.
Cada solicitud a un producto Lerian plantea dos preguntas: quién la hace y qué tiene permitido hacer. La autenticación responde a la primera; la autorización, a la segunda. **Access Manager** se encarga de ambas.
**Access Manager** es la capa de control de acceso de Lerian para nuestros productos y plugins. En lugar de cablear identidad y permisos en cada producto, los gestionas en un solo lugar: quiénes son tus usuarios, qué tokens portan y a qué pueden llegar esos tokens. Operadores, administradores e integraciones máquina a máquina pasan todos por la misma puerta, y cada uno solo toca los recursos para los que está autorizado.
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.
Cuando una solicitud llega a un producto protegido, Access Manager la verifica contra el sujeto, el recurso y la acción antes de ejecutar cualquier lógica de negocio. Un operador de back-office en un grupo como `midaz-viewer-group` puede leer datos de Midaz pero no modificarlos. Una integración de servicio que se autentica con credenciales de cliente obtiene exactamente el acceso máquina a máquina para el que fue configurada.
**Prueba el Access Manager localmente**
Ejecuta los plugins de Lerian sin desplegar en Kubernetes usando nuestro [repositorio plugins-docker-compose](https://github.com/LerianStudio/plugins-docker-compose).
Ten en cuenta que estos servicios requieren una licencia válida para ejecutarse. Sin ella, la aplicación no se iniciará. Para obtener detalles de la licencia, consulta nuestra [documentación de Licencia](/es/reference/lerians-license).
## ¿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:post` o `accounts: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.
Cómo encaja en tu stack depende de cómo lo despliegues:
* 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.
Access Manager está disponible como funcionalidad opcional en el modelo **Enterprise**. Si deseas obtener más información o evaluarlo para tu caso de uso, [ponte en contacto con nuestro equipo](https://lerian.studio/contact).
## Especificaciones técnicas
***
Lo que obtienes de fábrica:
* APIs REST para operaciones de [Auth](/es/reference/access-manager/am-auth-apis) e [Identity](/es/reference/access-manager/am-identity-apis).
* 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.
* Feature flag `PLUGIN_AUTH_ENABLED` para activar la aplicación de autorización a nivel de producto.
* 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:
| Capa | Para qué se usa |
| --------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| Bootstrap | Configuración inicial del entorno, incluyendo organizaciones base, roles integrados, grupos, aplicaciones y conjuntos de permisos. |
| Operación | Gestión diaria de usuarios, asignaciones de grupos, aplicaciones, proveedores, MFA y revisiones de acceso. |
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](/es/platform/access-manager/installing-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.
Los despliegues single-tenant se saltan todo esto y recurren a la organización predeterminada configurada.
No reutilices un token de un tenant para gestionar usuarios, aplicaciones o permisos en otro. Access Manager acota esas operaciones al contexto autenticado.
## 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.
[Explora la API de Access Manager](/es/reference/access-manager/am-api-introduction). Consulta los endpoints para usuarios, grupos, aplicaciones y permisos.