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 Lerian Cloud, ese token también lleva tu contexto de tenant, así que nunca pasas identificadores de tenant en payloads o headers. 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 Lerian Cloud, la lista cubre solo tu tenant. Usa los IDs de grupo devueltos tal como están cuando crees o actualices 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 Lerian Cloud, solo devuelve las aplicaciones de tu tenant.
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 de aplicaciones

Identity acepta solo nombres de aplicación de su catálogo cuando crea o elimina aplicaciones machine-to-machine. List Available Applications devuelve el catálogo, con el nombre y el nombre visible de cada aplicación.

​
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 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 por tenant en Lerian Cloud

En Lerian Cloud, Access Manager resuelve tu tenant a partir de tu token o de tu aplicación. Para password grants y SSO, Auth encuentra el tenant a partir de la dirección de correo electrónico del usuario. Identity solo permite crear un usuario nuevo cuando el dominio del correo coincide con el campo domain de tu organización, y rechaza al usuario con IDE-0034 cuando ese campo está vacío. 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.