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 quiénes son 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, confirma que el cliente de Auth en el nivel de ruta de cada producto está habilitado y configurado con una dirección de Auth. Las rutas protegidas esperan entonces un header Authorization que lleve un Bearer token válido.
Un producto con su cliente de Auth habilitado y configurado rechaza en sus rutas protegidas las solicitudes sin un Bearer token válido. Esto aplica incluso si el endpoint antes era alcanzable sin autenticación.
En despliegues SaaS y BYOC multi-tenant, ese token también lleva tu contexto de tenant en claims confiables, así que nunca pasas identificadores de tenant en payloads o headers. Conoce más 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. Las operaciones de creación, actualización y eliminación se quedan dentro de él.

​
Acceso humano

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

Inspecciona los grupos disponibles

Usa List Groups para ver los grupos disponibles en tu entorno.Usa Retrieve Group Details cuando necesites inspeccionar los permisos de un grupo específico antes de asignarlo.En despliegues multi-tenant, la lista cubre solo el tenant que lleva el Bearer token. Usa los IDs de grupo devueltos tal cual cuando creas o actualizas usuarios.
2

Revisa la superficie de permisos

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

Crea el usuario

Usa Create a User 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 Midaz de solo lectura permite que el usuario inspeccione recursos de Midaz sin cambiarlos.
4

Solicita un token de usuario

Usa Request an Access Token con el grant type password.Usa el access token devuelto como Bearer token cuando el usuario llama a APIs protegidas.
5

Renueva el token cuando sea necesario

Usa Refresh the Access Token para cambiar 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 machine-to-machine

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

Crea una aplicación

Usa Create an Application para crear credenciales para la integración.Se recomienda que cada integración tenga su propia aplicación. Esto hace más fácil la rotación de credenciales y la revisión de accesos. La respuesta incluye el clientId y el clientSecret que Auth usa en el flujo client_credentials.
2

Revisa o gestiona la aplicación

Usa List Applications, Retrieve Application Details o Delete Application cuando necesites revisar o quitar el acceso machine-to-machine.Identity oculta las aplicaciones internas de la lista. En despliegues multi-tenant, solo devuelve aplicaciones vinculadas a la organización de tenant del llamador.
3

Solicita un token de aplicación

Usa Request an Access Token con el grant type client_credentials.Usa el access token devuelto como Bearer token para las llamadas de API de la integración.

​
Catálogo actual de aplicaciones M2M

El catálogo actual de aplicaciones acepta estos nombres de aplicación cuando creas aplicaciones machine-to-machine: Identity acepta solo los nombres de este catálogo cuando crea o elimina aplicaciones machine-to-machine.

​
Configuración de proveedores

Usa proveedores cuando una aplicación necesita un proveedor de comunicación configurado para la entrega de MFA, como email o SMS. El SSO de navegador usa una configuración separada de proveedor OAuth y de política de SSO. Consulta el servicio Identity.
  1. Crea o revisa un proveedor con la API de Providers.
  2. Vincula el proveedor a la aplicación con Link Provider to Application.
  3. Si la aplicación tiene varios proveedores vinculados, usa Set Default Application Provider para elegir el proveedor predeterminado.
Usa los endpoints de aplicación y proveedor cuando necesites listar, actualizar, desvincular o reordenar los vínculos de proveedor 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

Empieza la configuración

Usa Initiate MFA Setup en la cuenta del propio usuario que inició sesión y en el método MFA elegido.
2

Verifica la configuración

Usa Verify MFA Passcode para confirmar el método.
3

Habilita MFA

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

Gestiona MFA a lo largo del tiempo

Usa Get MFA Status, Set Preferred MFA Method o Disable 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 Initiate MFA Challenge con el token MFA y el método elegido, y después Verify MFA Login, antes de recibir access tokens utilizables. Los cambios administrativos de MFA usan operaciones administrativas separadas.

​
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. Retrieve User Information devuelve su perfil compatible con OIDC, y Retrieve User Permissions muestra los recursos y las acciones que puede alcanzar. Para terminar una sesión, llama a End User Session con el campo de formulario obligatorio id_token_hint de esa sesión. Este endpoint no selecciona a otro usuario por ID.

​
Verificaciones de permisos

Los productos protegidos llaman a Auth con el recurso y la acción que necesitan aplicar. Usa Validate User Permission cuando una integración necesita verificar una decisión de acceso de forma explícita.
La respuesta te dice si el sujeto autenticado está autorizado para ese par de recurso y acción.

​
Reglas de acceso multi-tenant

El workflow de la API pública usa los mismos endpoints en despliegues single-tenant y multi-tenant, pero el comportamiento multi-tenant agrega 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 confiable del token o de la aplicación. Para los grants de password, Auth usa las credenciales de aplicación del tenant cuando están disponibles y mantiene el cache de tokens con reconocimiento de tenant. Identity también permite la creación de 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.
Así que no agregues IDs de tenant a los payloads de Identity o de Auth a menos que un endpoint documente ese campo de forma explícita. Después de la autenticación, los claims del Bearer token delimitan las llamadas normales de gestión de Identity y de permisos. Los grants de password y de client credentials resuelven el contexto de tenant antes de que exista un Bearer token.