Saltar al contenido principal

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.

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

​
Modelo de permisos

Access Manager evalúa la autorización con tres valores:
ValorSignificado
SujetoEl usuario autenticado o la aplicación máquina a máquina.
RecursoEl área protegida de un producto, como users, applications, accounts, reports o templates.
AcciónLa 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:
EjemploSignificado
users:getLeer usuarios.
applications:postCrear aplicaciones máquina a máquina.
reports:patchActualizar reportes.
templates:deleteEliminar plantillas de reportes.
Algunos productos usan acciones semánticas cuando la ruta no se describe mejor con un método HTTP:
EjemploSignificado
transfers:createCrear una transferencia de Bank Transfer.
transfers:processProcesar una transferencia de Bank Transfer.
system_config:readLeer la configuración de sistema de Bank Transfer.
workflows:activateActivar un workflow de Flowker.
Usa Obtener permisos del usuario para inspeccionar los recursos y acciones efectivos disponibles para el usuario autenticado.
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.

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

​
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. Para el lado de la decisión en tiempo de ejecución, consulta el servicio Auth. Para el flujo de trabajo del día a día contra las APIs, consulta Usar Access Manager.