> ## 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. Cuando un producto configura el control de acceso a nivel de ruta y su cliente Auth está habilitado, Auth evalúa el recurso y la acción solicitados antes de que se ejecute el handler del producto. Configura `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.

Cuando una solicitud llega a un producto cuyo cliente Auth a nivel de ruta está habilitado y configurado, 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 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.

<Tip>
  **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 configuración de licencia válida. Las comprobaciones de licencia se ejecutan mediante middleware HTTP, así que valida la licencia antes de habilitar productos protegidos. Para obtener detalles de la licencia, consulta nuestra [documentación de Licencia](/es/reference/lerians-license).
</Tip>

## ¿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.

<Tip>
  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).
</Tip>

## 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.
* 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:

| 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.

<Warning>
  No reutilices un token de un tenant para gestionar usuarios, aplicaciones o permisos en otro. Access Manager acota esas operaciones al contexto autenticado.
</Warning>

## 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.

<Tip>
  [Explora la API de Access Manager](/es/reference/access-manager/am-api-introduction). Consulta los endpoints para usuarios, grupos, aplicaciones y permisos.
</Tip>
