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.

Access Manager es la forma en que decides quién llega a tus productos Lerian y cómo los sistemas prueban su identidad antes de llamar a una API protegida. Esta guía recorre esa configuración con las APIs. Si prefieres trabajar de forma visual para las tareas comunes de usuarios y aplicaciones, usa Access Manager vía Lerian Console en su lugar.

​
Antes de empezar

Primero, asegúrate de que Access Manager esté habilitado para los productos que quieres proteger. A partir de ese punto, cada API protegida espera un encabezado Authorization con un bearer token válido. 
Authorization: Bearer <access_token>
Las solicitudes sin un bearer token válido se rechazan una vez que Access Manager está habilitado, incluso si el endpoint era accesible antes sin autenticación.
En despliegues multi-tenant SaaS y BYOC, ese token también lleva el contexto de tu tenant en claims de confianza como tenantId, de modo que nunca pasas identificadores de tenant en payloads ni en headers. Más información sobre multi-tenancy. Con las APIs de Identity, el token también es tu límite de tenant: los endpoints de listado devuelven solo los usuarios, grupos y aplicaciones de tu tenant, y las operaciones de creación, actualización y eliminación permanecen dentro de él.

​
Acceso humano

Sigue este flujo cuando una persona necesita acceder a los productos Lerian.
1

Inspecciona los grupos disponibles

Usa Listar grupos para ver los grupos disponibles en tu entorno.Usa Obtener detalles del grupo cuando necesites inspeccionar los permisos de un grupo específico antes de asignarlo.En despliegues multi-tenant, la lista se delimita al tenant que lleva el bearer token. Usa los IDs de grupo devueltos tal cual al crear o actualizar usuarios.
2

Revisa la superficie de permisos

Comprueba los recursos y acciones de cada grupo antes de asignarlo. Los permisos de Access Manager se evalúan como pares exactos de recurso-acción, como reports:get, users:patch o transfers:read.Algunos productos usan acciones al estilo de los métodos HTTP, mientras que otros usan acciones semánticas como read, write, create o process. Usa los permisos que devuelve la API en lugar de derivar nombres de permisos a partir de las rutas de los endpoints.
3

Crea el usuario

Usa Crear un usuario y asigna los grupos correctos durante la creación.La asignación de grupos define a qué puede acceder el usuario. Por ejemplo, asignar un grupo de solo lectura de Midaz permite al usuario inspeccionar recursos de Midaz sin modificarlos.
4

Solicita un token de usuario

Usa Solicitar un token de acceso con el tipo de concesión password.El access token devuelto se usa como bearer token cuando el usuario llama a las APIs protegidas.
5

Renueva el token cuando sea necesario

Usa Renovar el token de acceso para intercambiar un refresh token válido por un nuevo access token.

​
Endpoints de gestión de usuarios

Usa estos endpoints para mantener el acceso humano a lo largo del tiempo:

​
Acceso máquina a máquina

Cuando un servicio, job o integración necesita llamar a las APIs de Lerian sin una persona de por medio, dale su propia aplicación.
1

Crea una aplicación

Usa Crear una aplicación para crear credenciales para la integración.Cada integración debe tener su propia aplicación. Esto facilita la rotación de credenciales y las revisiones de acceso. La respuesta incluye el clientId y el clientSecret que usa Auth en el flujo client_credentials.
2

Revisa o gestiona la aplicación

Usa Listar aplicaciones, Obtener una aplicación o Eliminar una aplicación cuando necesites revisar o eliminar el acceso máquina a máquina.Identity oculta las aplicaciones internas de la lista. En despliegues multi-tenant, solo devuelve las aplicaciones vinculadas a la organización del tenant de quien hace la llamada.
3

Solicita un token de aplicación

Usa Solicitar un token de acceso con el tipo de concesión client_credentials.El access token devuelto se usa como bearer token para las llamadas a la API de la integración.

​
Catálogo actual de aplicaciones M2M

La semilla y las migraciones actuales de Access Manager definen permisos M2M para estos nombres de aplicación:
Nombre de la aplicaciónProducto
midazMidaz Ledger
plugin-feesFees Engine
plugin-crmCRM
reporterReporter
plugin-br-pix-direct-jdPix Direct JD
plugin-br-pix-indirect-btgPix Indirect BTG
plugin-br-bank-transferBank Transfer
Otros productos listados en la matriz de habilitación, como Tracer, Flowker y Fetcher, actualmente no definen nombres estándar de aplicaciones M2M en el seed de Access Manager. No crees aplicaciones con nombres fuera de este catálogo a menos que tu entorno tenga un conjunto de permisos personalizado para esa aplicación.

​
Configuración de proveedores

Usa proveedores cuando una aplicación necesita un proveedor de comunicación configurado para entrega de MFA, como email o SMS.
  1. Crea o revisa un proveedor con la API de proveedores.
  2. Vincula el proveedor a la aplicación con Vincular un proveedor a una aplicación.
  3. Si la aplicación tiene varios proveedores vinculados, usa Establecer el proveedor predeterminado de una aplicación para seleccionar el proveedor predeterminado.
Usa los endpoints de proveedor-aplicación cuando necesites listar, actualizar, desvincular o reordenar los vínculos de proveedores de una aplicación.

​
Configuración de MFA

Usa MFA para los usuarios que necesitan un paso adicional de verificación al iniciar sesión.
1

Inicia la configuración

Usa Iniciar la configuración de MFA para el usuario y el método MFA.
2

Verifica la configuración

Usa Verificar el código de MFA para confirmar el método.
3

Habilita MFA

Usa Habilitar MFA después de verificar la configuración.
4

Gestiona MFA a lo largo del tiempo

Usa Obtener el estado de MFA, Establecer el método de MFA preferido o Deshabilitar MFA a medida que cambian los requisitos de acceso del usuario.
Durante el inicio de sesión, los usuarios con MFA habilitado pueden necesitar completar Iniciar el desafío de MFA y Verificar el desafío de MFA antes de recibir access tokens utilizables.

​
Información de usuario y control de sesión

Una vez que un usuario está activo, algunos endpoints te ayudan a inspeccionar y controlar la sesión. Obtener información del usuario devuelve su perfil compatible con OIDC, y Obtener permisos del usuario muestra los recursos y acciones a los que puede acceder. Cuando necesitas terminar una sesión antes de tiempo y revocar sus tokens activos, llama a Finalizar sesión del usuario.

​
Comprobaciones de permisos

Los productos protegidos llaman a Auth con el recurso y la acción que necesitan aplicar. Usa Validar permisos del usuario cuando una integración necesita comprobar una decisión de acceso de forma explícita. 
{
  "resource": "reports",
  "action": "get"
}
La respuesta te indica si el sujeto autenticado está autorizado para ese par recurso-acción.

​
Reglas de acceso multi-tenant

El flujo de trabajo de la API es idéntico en despliegues single-tenant y multi-tenant. Lo único que cambia es de dónde obtiene Access Manager el alcance del tenant:
  • En despliegues multi-tenant, Auth e Identity resuelven el tenant a partir del contexto de confianza del token o de la aplicación.
  • En despliegues single-tenant, Access Manager usa la organización predeterminada configurada.
Por eso no añadas IDs de tenant a los payloads de Identity o Auth a menos que un endpoint documente explícitamente ese campo. Para los flujos normales de usuario, grupo, aplicación, token y permisos, el bearer token es tu única fuente del alcance del tenant.