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

# Control de acceso a nivel de producto

> Entiende cómo los productos protegidos de Lerian aplican las decisiones de Access Manager a nivel de ruta, llamando a Auth antes de que se ejecute la lógica de negocio.

El control de acceso a nivel de producto es la integración en tiempo de ejecución dentro de cada producto protegido de Lerian. No es un tercer servicio de Access Manager. Es el código a nivel de ruta que llama a Auth en cada solicitud entrante y que deja continuar la solicitud o la rechaza antes de que se ejecute el handler del producto.

Identity define los datos de acceso. Auth decide si un sujeto puede realizar una acción sobre un recurso. El control de acceso a nivel de producto es donde esas decisiones se aplican realmente al tráfico en vivo.

## Qué hace

***

En cada solicitud protegida, el producto:

* lee el bearer token del header `Authorization`;
* construye una verificación de permiso con el `sub` (sujeto) del token, el `resource` configurado para la ruta y el `action` configurado para la ruta;
* envía esa verificación a Auth;
* continúa con el handler del producto cuando Auth devuelve una decisión autorizada;
* rechaza la solicitud con el error HTTP o gRPC correspondiente cuando Auth la deniega;
* usa claims confiables del token, como `tenantId`, cuando se requiere autorización con conciencia de tenant.

Por ejemplo, una ruta de Midaz puede proteger `POST /transactions` con el recurso `transactions` y la acción `post`. Auth decide si el sujeto del bearer token tiene ese permiso para el tenant que viaja en el mismo token.

<Warning>
  El control de acceso a nivel de producto no gestiona usuarios, no emite tokens ni almacena datos de políticas. Llama a Auth y actúa según la respuesta.
</Warning>

## Modelo de permisos

***

Access Manager evalúa la autorización con tres valores:

| Valor   | Significado                                                                                          |
| ------- | ---------------------------------------------------------------------------------------------------- |
| Sujeto  | El usuario autenticado o la aplicación máquina a máquina.                                            |
| Recurso | El área protegida de un producto, como `users`, `applications`, `accounts`, `reports` o `templates`. |
| Acción  | La operación solicitada, como `get`, `post`, `patch`, `delete`, `read` o `write`.                    |

Los usuarios humanos reciben permisos a través de grupos. Cada grupo está vinculado a uno o más roles de producto, y cada rol otorga acceso a un conjunto definido de recursos y acciones.

Las aplicaciones máquina a máquina reciben permisos a través de su identidad de aplicación. Auth resuelve la aplicación que realiza la llamada y la verifica contra el conjunto de permisos configurado para esa aplicación.

### Nombres de recursos y acciones

Los nombres de recursos y acciones son strings exactos. Deben coincidir con los valores configurados para la ruta del producto, y la ruta envía esos valores configurados a Auth.

La mayoría de los productos de API usan acciones al estilo de los métodos HTTP:

| Ejemplo             | Significado                           |
| ------------------- | ------------------------------------- |
| `users:get`         | Leer usuarios.                        |
| `applications:post` | Crear aplicaciones máquina a máquina. |
| `reports:patch`     | Actualizar reportes.                  |
| `templates:delete`  | Eliminar plantillas de reportes.      |

Algunos productos usan acciones semánticas cuando la ruta no se describe mejor con un método HTTP:

| Ejemplo              | Significado                                        |
| -------------------- | -------------------------------------------------- |
| `transfers:create`   | Crear una transferencia de Bank Transfer.          |
| `transfers:process`  | Procesar una transferencia de Bank Transfer.       |
| `system_config:read` | Leer la configuración de sistema de Bank Transfer. |
| `workflows:activate` | Activar un workflow de Flowker.                    |

Usa [Obtener permisos del usuario](/es/reference/access-manager/retrieve-user-permissions) para inspeccionar los recursos y acciones efectivos disponibles para el usuario autenticado.

<Warning>
  No deduzcas los strings de permiso a partir de las rutas de los endpoints por convención. Los productos protegidos aplican los valores de recurso y acción configurados en Access Manager, no valores inferidos de la URL.
</Warning>

## Flujo de la solicitud

***

1. **Recibir la solicitud**
   * El producto lee el bearer token del header `Authorization`.
   * Si el token falta o está mal formado, la solicitud se rechaza antes de intentar cualquier verificación de permiso.
2. **Construir la verificación de permiso**
   * El producto usa el recurso y la acción configurados para la ruta.
   * En despliegues con conciencia de tenant, el producto se apoya en el claim `tenantId` ya presente en el token en lugar de leer identificadores de tenant desde headers o payloads.
3. **Consultar a Auth**
   * El producto llama a Auth con el sujeto, el recurso y la acción.
   * Auth evalúa la solicitud contra los permisos configurados en Access Manager y puede servir la respuesta desde caché.
4. **Aplicar la decisión**
   * Si está autorizada, el producto continúa hacia su handler.
   * Si está denegada, el producto devuelve el error HTTP o gRPC correspondiente y no invoca la lógica de negocio.

<Note>
  El alcance del tenant se establece a partir del token. En despliegues SaaS y BYOC multi-tenant, el claim `tenantId` lo resuelve automáticamente la plataforma en cada solicitud de API, por lo que no necesitas pasar un identificador de tenant en headers o cuerpos de solicitud. Aprende más sobre [multi-tenancy](/es/multi-tenancy).
</Note>

## Dónde encaja

***

El control de acceso a nivel de producto se sitúa entre la red y el handler del producto. Es la razón por la que se requiere un bearer token válido en cada ruta protegida después de habilitar Access Manager, y la razón por la que un sujeto autorizado aún necesita el permiso de recurso-acción correcto para llegar a una operación específica.

Para el lado de gestión de este panorama, consulta el [servicio Identity](/es/platform/access-manager/identity-plugin). Para el lado de la decisión en tiempo de ejecución, consulta el [servicio Auth](/es/platform/access-manager/auth-plugin). Para el flujo de trabajo del día a día contra las APIs, consulta [Usar Access Manager](/es/platform/access-manager/using-access-manager).