> ## 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. # Servicio Identity > Gestiona usuarios, grupos, roles, aplicaciones, proveedores, configuración SSO y MFA con el servicio Identity. 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 pertenece cada persona, qué aplicaciones pueden autenticarse con credenciales máquina a máquina y qué proveedores de comunicación u OAuth están disponibles. Identity no emite tokens de acceso 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 permisos directos; * crear, actualizar, listar o eliminar grupos e inspeccionar sus permisos; * crear, actualizar, listar o eliminar roles personalizados con alcance de tenant y asignar sus permisos, usuarios y grupos; * crear, listar, recuperar o eliminar aplicaciones máquina a máquina; * crear, actualizar, listar, recuperar o eliminar proveedores de comunicación; * vincular proveedores a aplicaciones y seleccionar el proveedor predeterminado; * configurar la política SSO y el proveedor OAuth activo del tenant; * iniciar, verificar, activar, desactivar, revisar o cambiar la configuración de MFA de los usuarios; * restablecer o actualizar contraseñas de usuario. ## Usuarios y grupos *** El acceso humano se gestiona 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, un usuario puede asignarse a un grupo viewer de Midaz para inspeccionar datos del ledger sin modificarlos, y a un grupo contributor de Reporter para crear plantillas de reportes. Un usuario también puede recibir un permiso directo sin pertenecer a un grupo para ese producto. Identity expone endpoints de usuario para listar usuarios, crear usuarios, recuperar 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 listado de usuarios y grupos están paginados con `page` y `limit`. En despliegues multi-tenant, los usuarios y grupos se acotan a partir del bearer token. El servicio lee la organización de tenant del contexto autenticado y devuelve solo los usuarios y 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](/es/reference/access-manager/list-groups). La API se encarga del prefijado interno de la organización; los clientes no deben construir manualmente valores `organization/group` al estilo de Casdoor. No envíes la pertenencia de tenant en los payloads de usuario. Identity deriva el alcance de tenant del bearer token y luego aplica los cambios de usuario y grupo solicitados dentro de ese tenant. ### Roles Access Manager usa niveles de rol como una convención común entre productos. Las acciones efectivas de cada rol provienen del conjunto de permisos del producto o la aplicación. Identity también admite roles personalizados con alcance de tenant. | Rol | Acceso típico | | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | Admin | Acceso completo, incluidas las operaciones administrativas. | | Editor | Puede leer, crear, actualizar y eliminar recursos. | | Contributor | Normalmente puede leer, crear y actualizar recursos. El acceso de eliminación depende del conjunto de permisos del producto o de la aplicación. | | Viewer | Acceso de solo lectura. | Los roles tienen alcance por producto o aplicación. Un usuario puede ser Editor en Midaz, Viewer en Reporter y no tener acceso a Fees. Access Manager proporciona el catálogo de permisos de la plataforma. Puedes crear, actualizar y eliminar grupos con alcance de tenant; después usa [Listar grupos](/es/reference/access-manager/list-groups) y [Obtener detalles del grupo](/es/reference/access-manager/retrieve-group-details) para inspeccionar los grupos disponibles en tu entorno. Las asignaciones de grupo son una forma de otorgar acceso; Identity también admite la asignación directa de permisos a usuarios. 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 grupo para un producto puede conservar acceso mediante permisos directos de usuario. Comprueba sus permisos efectivos antes de concluir que no puede acceder a un producto. Para el modelo de recurso-acción, los vocabularios de acciones que usa cada producto y cómo se protegen las rutas en tiempo de ejecución, consulta [Aplicación a nivel de producto](/es/platform/access-manager/product-level-enforcement). Para el flujo de API que une usuarios, grupos y tokens, consulta [Usar Access Manager](/es/platform/access-manager/using-access-manager). ## Aplicaciones *** Las aplicaciones representan clientes máquina a máquina para el grant `client_credentials`. Úsalas cuando un servicio, job o 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`. Tras crear una aplicación, la integración puede solicitar un token de acceso a Auth y llamar a las APIs Lerian protegidas según sus permisos configurados. Identity admite: * listar aplicaciones; * crear aplicaciones; * recuperar detalles de 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 flujo de trabajo. El catálogo actual de permisos M2M incluye estos nombres de aplicación: | Nombre de aplicación | Uso típico | | ---------------------------- | -------------------------------------------------------------- | | `midaz` | Automatización del ledger central. | | `plugin-fees` | Automatización de paquetes de tarifas, tarifas y estimaciones. | | `plugin-crm` | Automatización de holders y alias del CRM. | | `reporter` | Automatización de reportes y plantillas. | | `fetcher` | Automatización de ingestión de Fetcher. | | `plugin-br-pix-jd` | Automatización de Pix Directo JD. | | `plugin-br-pix-indirect-btg` | Automatización de Pix Indirect BTG. | | `plugin-br-bank-transfer` | Automatización de Bank Transfer. | | `plugin-br-pix-switch-spi` | Automatización de Pix Switch SPI. | | `plugin-br-pix-switch-dict` | Automatización de Pix Switch DICT. | | `plugin-br-pix-switch-cob` | Automatización de Pix Switch COB. | | `flowker` | Automatización de workflows de Flowker. | | `streaming-hub` | Automatización de Streaming Hub. | | `br-sta` | Automatización de transferencia de archivos STA. | | `br-sisbajud` | Automatización de Sisbajud. | Los nombres de aplicación son identificadores de producto, no etiquetas de visualización de la interfaz. Identity acepta solo los nombres de este catálogo al crear o eliminar aplicaciones. Algunos productos, como Tracer, tienen conjuntos de permisos M2M gestionados por la plataforma y sembrados por Access Manager, pero no forman parte de este catálogo de creación self-service. Identity filtra las aplicaciones internas de la lista pública de aplicaciones. En modo multi-tenant, también devuelve solo las aplicaciones vinculadas a la organización de tenant de quien llama. ### Acotación 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 de quien llama; * las listas de grupos incluyen solo los grupos de permisos disponibles en ese tenant; * las listas de aplicaciones incluyen solo las aplicaciones máquina a máquina vinculadas 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 mutar los usuarios, grupos o aplicaciones de otro tenant a través de las APIs públicas de Identity. ## Proveedores de comunicación *** Los proveedores de comunicación definen los servicios de entrega de email o SMS disponibles para las aplicaciones, incluidos los flujos de MFA. Se gestionan por separado de las aplicaciones para que el mismo proveedor pueda reutilizarse y controlarse de forma consistente. Identity admite: * listar proveedores; * crear proveedores; * recuperar detalles de proveedor; * actualizar proveedores; * eliminar proveedores. Identity también admite los vínculos aplicación-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; * establecer 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. Configurar un proveedor SSO deshabilita el inicio de sesión local con contraseña de forma predeterminada; configura la política SSO explícitamente si el tenant debe conservarlo. La URL de callback SSO de Auth debe ser una URL absoluta y aparecer en la lista de redirecciones permitidas de la aplicación; de lo contrario, fallará el relay del código de autorización. ## 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: * iniciar la configuración de MFA; * verificar un código de acceso de MFA durante la configuración; * activar MFA tras la verificación; * desactivar MFA; * recuperar el estado actual de MFA; * establecer el método de MFA preferido. MFA puede usar métodos admitidos como aplicación de autenticación, correo electrónico 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 de autoservicio: el sujeto del token de quien llama debe coincidir con el usuario objetivo. Las operaciones administrativas de MFA son independientes y se aplican solo a los métodos que admiten esas operaciones. ## Arquitectura y flujo de identidad *** Arquitectura de identidad que muestra cómo el plugin de identidad gestiona los perfiles de usuario y los métodos de MFA a lo largo del flujo de autenticación 1. **Solicitud de gestión** * Un administrador o 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. Configura `AUTH_REQUIRED=true` cuando el despliegue deba rechazar 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 SSO o 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, permisos y MFA. * Los productos Lerian protegidos dependen de las decisiones de Auth antes de procesar operaciones de producto. ## Descripción general de la API *** Identity expone APIs para: * usuarios; * grupos; * roles personalizados y sus asignaciones; * aplicaciones; * proveedores; * vínculos aplicación-proveedor; * política SSO y configuración de proveedores OAuth; * configuración y gestión de MFA; * configuración de allowlist IP del tenant; * gestión de perfil y teléfono de autoservicio; * flujos de restablecimiento y actualización de contraseña. Cuando su cliente Auth está habilitado y configurado, Identity protege el acceso de gestión mediante permisos de Access Manager. Para obtener detalles técnicos, consulta la documentación de [APIs de Identity](/es/reference/access-manager/am-identity-apis).