Skip to main content
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 el cliente Auth a nivel de ruta de cada producto esté habilitado y configurado con una dirección de Auth. Las rutas protegidas esperan entonces un encabezado Authorization con un bearer token válido.
Cuando el cliente Auth de un producto está habilitado y configurado, las solicitudes sin un bearer token válido se rechazan en sus rutas protegidas, 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

El catálogo actual de aplicaciones acepta estos nombres al crear aplicaciones machine-to-machine: Identity acepta solo los nombres de este catálogo al crear o eliminar aplicaciones máquina a máquina.

​
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. El SSO en navegador usa una configuración independiente de proveedor OAuth y política SSO; consulta el servicio Identity.
  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 en la propia cuenta del usuario autenticado y para el método MFA seleccionado.
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 con el token MFA y el método seleccionado, y después Verificar el desafío de MFA, antes de recibir access tokens utilizables. Los cambios administrativos de MFA usan operaciones administrativas independientes.

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

Una vez que un usuario está activo, algunos endpoints ayudan a inspeccionar y controlar esa 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. Para finalizar una sesión, llama a Finalizar sesión del usuario con el campo de formulario obligatorio id_token_hint de esa sesión; este endpoint no selecciona a otro usuario por ID.

​
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.
La respuesta te indica si el sujeto autenticado está autorizado para ese par recurso-acción.

​
Reglas de acceso multi-tenant

El flujo público de la API usa los mismos endpoints en despliegues single-tenant y multi-tenant, pero el comportamiento multi-tenant añade resolución y validación de credenciales específicas 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. Para las concesiones de contraseña, Auth usa credenciales de aplicación del tenant cuando están disponibles y mantiene la caché de tokens consciente del tenant. Identity también permite crear usuarios nuevos solo cuando puede confirmar que el dominio de email coincide con el administrador de referencia del tenant.
  • 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. Después de la autenticación, las claims del bearer token acotan las llamadas normales de gestión y permisos de Identity. Las concesiones de contraseña y client credentials resuelven el contexto de tenant antes de que exista un bearer token.