Skip to main content
Identity es el servicio de gestión de Access Manager. Es donde los administradores definen quién puede acceder a los productos Lerian: a qué grupos y roles pertenecen las personas, qué aplicaciones pueden autenticarse con credenciales machine-to-machine y qué proveedores de comunicación u OAuth están disponibles. Identity no emite access tokens ni toma decisiones de autorización en tiempo de ejecución. Auth usa los datos de identidad que se gestionan aquí para autenticar sujetos y evaluar permisos. Usa Identity cuando necesites:
  • crear, actualizar, listar o eliminar usuarios.
  • asignar usuarios a grupos de producto o a permisos directos.
  • crear, actualizar, listar o eliminar grupos e inspeccionar sus permisos.
  • crear, actualizar, listar o eliminar roles personalizados acotados al tenant y asignar sus permisos, usuarios y grupos.
  • crear, listar, obtener o eliminar aplicaciones machine-to-machine.
  • crear, actualizar, listar, obtener o eliminar proveedores de comunicación.
  • vincular proveedores a aplicaciones y seleccionar el proveedor predeterminado.
  • configurar la política de SSO y el proveedor OAuth activo del tenant.
  • empezar, verificar, habilitar, deshabilitar, revisar o cambiar los ajustes de MFA de los usuarios.
  • restablecer o actualizar contraseñas de usuario.

​
Usuarios y grupos

Identity gestiona el acceso humano mediante usuarios, grupos y permisos directos de usuario. Un grupo representa un conjunto de permisos para un producto o un área de Access Manager. Por ejemplo, puedes asignar un usuario a un grupo de viewer de Midaz para inspeccionar datos del ledger sin cambiarlos. También puedes asignar ese usuario a un grupo de contributor de Reporter para crear plantillas de informes. Un usuario también puede recibir un permiso directo sin pertenecer a un grupo de ese producto. Identity expone endpoints de usuario para listar usuarios, crear usuarios, obtener un usuario, actualizar la información de usuario, gestionar asignaciones de grupo y permisos directos, eliminar usuarios, actualizar contraseñas y restablecer contraseñas. Los endpoints de lista de usuarios y de grupos usan page y limit para la paginación. En despliegues multi-tenant, el servicio acota los usuarios y los grupos a partir del Bearer token. El servicio lee la organización de tenant del contexto autenticado y devuelve solo los usuarios y los grupos que pertenecen a ese tenant. En despliegues single-tenant, los mismos endpoints devuelven el conjunto de todo el entorno. Cuando creas o actualizas un usuario, envía los IDs de grupo que devuelve Listar grupos. La API se encarga del prefijo interno de organización. Se recomienda que los clientes no construyan valores organization/group a mano.
No envíes la pertenencia de tenant en los payloads de usuario. Identity deriva el ámbito de tenant del Bearer token y luego aplica los cambios de usuario y de grupo solicitados dentro de ese tenant.

​
Roles

Access Manager usa niveles de rol como convención común en los productos. Las acciones efectivas de cada rol vienen del conjunto de permisos del producto o de la aplicación. Identity también admite roles personalizados acotados al tenant.
El ámbito del rol es por producto o aplicación. Un usuario puede ser Editor en Midaz, Viewer en Reporter y no tener acceso a Fees.
Access Manager aporta el catálogo de permisos de la plataforma. Puedes crear, actualizar y eliminar grupos acotados al tenant, y luego usar Listar grupos y Obtener detalles del grupo para inspeccionar los grupos disponibles en tu entorno. Las asignaciones de grupo son una manera de otorgar acceso. Identity también admite la asignación directa de permisos de usuario. Puedes crear roles personalizados y asignarles permisos, usuarios y grupos. Los roles de sistema integrados son inmutables: Identity rechaza los intentos de crearlos, actualizarlos o eliminarlos. Usa roles personalizados cuando los niveles de rol estándar no expresen el modelo de acceso que necesitas.
Un usuario sin un grupo para un producto aún puede tener acceso mediante permisos directos de usuario. Revisa los permisos efectivos del usuario antes de concluir que no puede acceder a un producto.
Para el modelo de recurso y acción, los vocabularios de acción que usa cada producto y cómo se protegen las rutas en tiempo de ejecución, consulta Aplicación en el nivel de producto. Para el workflow de la API que une usuarios, grupos y tokens, consulta Usar Access Manager.

​
Aplicaciones

Las aplicaciones representan clientes machine-to-machine para el grant client_credentials. Úsalas cuando un servicio, un job o una integración necesita autenticarse sin un usuario humano. Una aplicación almacena el clientId y el clientSecret que usa Auth durante el flujo client_credentials. Después de crear una aplicación, la integración puede solicitar un access token a Auth y llamar a las APIs Lerian protegidas según sus permisos configurados. Identity admite:
  • listar aplicaciones.
  • crear aplicaciones.
  • obtener los detalles de una aplicación.
  • eliminar aplicaciones.
Por ejemplo, un job de conciliación puede usar una aplicación de Bank Transfer para solicitar un token y llamar solo a los endpoints que necesita su workflow. El catálogo actual de permisos M2M incluye estos nombres de aplicación: Los nombres de aplicación son identificadores de producto, no etiquetas visibles de la interfaz. Identity acepta solo los nombres de este catálogo cuando crea o elimina aplicaciones. Algunos productos, como Tracer, tienen conjuntos de permisos M2M gestionados por la plataforma e inicializados por Access Manager, pero no forman parte de este catálogo de creación autoservicio. Para el alcance de la versión v1.0.0 de Pix Lerian, consulta Variables de entorno de Pix Lerian.
Identity filtra las aplicaciones internas de la lista pública de aplicaciones. En modo multi-tenant, también devuelve solo las aplicaciones ligadas a la organización de tenant del llamador.

​
Acotamiento por tenant

En despliegues multi-tenant, Identity usa el contexto autenticado como el límite de tenant para las operaciones de gestión:
  • las operaciones de usuario aplican a la organización de tenant del llamador.
  • las listas de grupos incluyen solo los grupos de permisos disponibles en ese tenant.
  • las listas de aplicaciones incluyen solo las aplicaciones machine-to-machine ligadas a ese tenant.
  • las credenciales de aplicación creadas para una integración pertenecen al tenant que las creó.
Esto mantiene el acceso operativo local al tenant. Un token de administrador de un tenant no puede listar ni modificar los usuarios, los grupos ni las aplicaciones de otro tenant mediante las APIs públicas de Identity.

​
Proveedores de comunicación

Los proveedores de comunicación definen los servicios de entrega por correo o SMS disponibles para las aplicaciones, incluidos los flujos de MFA. Identity gestiona los proveedores por separado de las aplicaciones. Así puedes reusar y controlar el mismo proveedor de forma consistente. Identity admite:
  • listar proveedores.
  • crear proveedores.
  • obtener los detalles de un proveedor.
  • actualizar proveedores.
  • eliminar proveedores.
Identity también admite los vínculos entre aplicación y proveedor:
  • listar los proveedores vinculados a una aplicación.
  • vincular un proveedor a una aplicación.
  • actualizar un vínculo de proveedor.
  • desvincular un proveedor de una aplicación.
  • definir el proveedor predeterminado de una aplicación.
Usa un proveedor predeterminado cuando una aplicación tiene más de un proveedor vinculado y necesita una ruta de autenticación preferida. Para SSO, Identity gestiona un proveedor OAuth activo por tenant. Los tipos de proveedor admitidos son Google, Microsoft, Okta y Custom. Cuando configuras el primer proveedor SSO sin disablePasswordLogin, el inicio de sesión local con contraseña sigue disponible hasta que el tenant completa su primer inicio de sesión SSO exitoso, y entonces Auth lo deshabilita. Define disablePasswordLogin de forma explícita para controlarlo de inmediato: true deshabilita el inicio de sesión local con contraseña y false lo mantiene habilitado. La URL de callback SSO de Auth debe ser una URL absoluta y aparecer en la lista de URI de redirección permitidas de la aplicación, o la retransmisión del código de autorización falla. Antes de guardar un proveedor SSO candidato, ejecuta su validación previa. Revisa la configuración, el descubrimiento del endpoint OIDC, las credenciales de cliente y la URI de redirección del callback sin crear ni cambiar un proveedor, un vínculo entre aplicación y proveedor, o una aplicación. El resultado de la validación informa una verificación fallida. Una solicitud mal formada o no autorizada devuelve un error HTTP. Para un despliegue BYOC single-tenant con una sola organización fija de Caradhras, define PLUGIN_AUTH_SSO_STATIC_ORGANIZATION en Auth. El SSO previo al inicio de sesión resuelve entonces cada solicitud a esa organización en lugar de buscar una etiqueta de organización domain:. No definas esta variable cuando MULTI_TENANT_ENABLED=true.

​
Gestión de MFA

Identity gestiona la configuración de MFA de los usuarios. Auth usa esa configuración durante el inicio de sesión cuando se requiere MFA. Identity admite:
  • empezar la configuración de MFA.
  • verificar un código de acceso MFA durante la configuración.
  • habilitar MFA después de la verificación.
  • deshabilitar MFA.
  • obtener el estado actual de MFA.
  • definir el método MFA preferido.
MFA puede usar métodos admitidos como una aplicación de autenticación, correo o SMS, según la configuración del entorno y los datos de perfil de usuario disponibles. Las operaciones estándar de configuración y gestión de MFA son autoservicio: el sujeto del token del llamador debe coincidir con el usuario objetivo. Las operaciones administrativas de MFA son aparte y aplican solo a los métodos que esas operaciones admiten.

​
Arquitectura y flujo de identidad

Arquitectura de Identity que muestra cómo el plugin de identidad gestiona los perfiles de usuario y los métodos MFA en el flujo de autenticación

Figura 1. Flujo de identidad

  1. Solicitud de gestión
    • Un administrador o un cliente autorizado llama a una API de Identity.
    • Cuando el cliente Auth de Identity está habilitado y configurado, la solicitud se autentica y se verifica contra los permisos de Access Manager. Define AUTH_REQUIRED=true cuando el despliegue deba rechazar las solicitudes de gestión si ese cliente no está disponible o está mal configurado.
  2. Procesamiento de la solicitud
    • Identity valida el payload y aplica la operación solicitada.
    • El servicio actualiza usuarios, grupos, roles, aplicaciones, proveedores, vínculos de proveedor, configuración de SSO o configuración de MFA en el sistema de identidad configurado.
  3. Uso en tiempo de ejecución
    • Auth lee los datos de identidad resultantes durante los flujos de token, de permisos y de MFA.
    • Los productos Lerian protegidos dependen de las decisiones de Auth antes de procesar las operaciones del producto.

​
Resumen de la API

Identity expone APIs para:
  • usuarios.
  • grupos.
  • roles personalizados y sus asignaciones.
  • aplicaciones.
  • proveedores.
  • vínculos entre aplicación y proveedor.
  • la política de SSO y la configuración del proveedor OAuth.
  • la configuración y la gestión de MFA.
  • la configuración de la lista de IP permitidas del tenant.
  • la gestión autoservicio del perfil y del teléfono.
  • los flujos de restablecimiento y de actualización de contraseña.
Cuando su cliente Auth está habilitado y configurado, Identity protege el acceso de gestión mediante los permisos de Access Manager. Para detalles técnicos, consulta la documentación de las APIs de Identity.