La asignación de grupos SAML asigna acceso al equipo de Apidog desde los grupos incluidos en la aserción SAML de un usuario. Reduce el trabajo manual de membresía de equipo mientras mantiene al proveedor de identidad como la fuente de membresía de grupo.
Este tutorial utiliza Microsoft Entra ID. Añadirás una reclamación `groups`, asignarás un grupo de Entra a un equipo de Apidog y verificarás los permisos iniciales del proyecto asignados al iniciar sesión.
Antes de empezar
Necesitas:
- una organización Apidog Enterprise con SAML SSO ya configurado;
- acceso de Propietario de la Organización o Administrador de la Organización en Apidog;
- acceso de administrador a la aplicación empresarial de Microsoft Entra utilizada para Apidog;
- al menos un grupo de Entra y un usuario de prueba asignado a ese grupo.
Si SAML aún no está configurado, completa primero Configuración de Microsoft Entra ID.
La asignación de grupos SAML controla el acceso a los equipos y proyectos de Apidog. No otorga acceso a las API de producción ni reemplaza la autorización en tiempo de ejecución.
Cómo se asigna el acceso inicial al proyecto
Cuando un grupo coincide, Apidog añade al usuario al equipo asignado y deriva el acceso inicial al proyecto del rol de equipo seleccionado.
| Rol de equipo asignado | Rol inicial del proyecto |
|---|---|
| Administrador de Equipo | Mantenedor de Proyecto |
| Miembro de Equipo | Solo Lectura de Proyecto |
| Invitado de Equipo | Solo Lectura de Proyecto |
Apidog crea membresías de proyecto faltantes o actualiza las membresías de proyecto que aún no tienen un rol. Un rol de proyecto existente asignado manualmente no se sobrescribe durante inicios de sesión SAML posteriores.
Paso 1: Añadir la reclamación `groups` en Microsoft Entra ID
- Inicia sesión en el centro de administración de Microsoft Entra.
- Ve a Aplicaciones empresariales y abre la aplicación utilizada para Apidog SSO.
- Selecciona Inicio de sesión único, luego abre Atributos y reclamaciones.
- Selecciona Añadir una reclamación de grupo.
- Elige Todos los grupos.
- Habilita Personalizar el nombre de la reclamación de grupo e ingresa `groups` como el nombre de la reclamación.
- Guarda la reclamación.
Configura la reclamación de grupo para que Apidog reciba los ID de objeto del grupo de Entra en el atributo groups.
Apidog utiliza los ID de objeto del grupo en esta reclamación. No recupera otra información sobre los grupos de Microsoft Entra ID.
Paso 2: Copiar el nombre del grupo de Entra y el ID de objeto
- En Microsoft Entra ID, abre Grupos.
- Selecciona el grupo que debe recibir acceso en Apidog.
- Copia su Nombre y ID de objeto.
Utiliza el ID de objeto que se muestra en la página del grupo de Entra. No uses un ID de aplicación, ID de inquilino o nombre para mostrar en lugar del ID de objeto.
Mantén esta página disponible mientras configuras la asignación en Apidog.
Paso 3: Asignar el grupo a un equipo de Apidog
- Abre la organización en Apidog.
- Ve a la configuración de Grupo SAML de la organización.
- Añade una asignación de grupo.
- Ingresa el nombre del grupo de Entra y pega su ID de objeto.
- Selecciona el equipo o los equipos de Apidog a los que el grupo debe tener acceso.
- Elige el rol de equipo requerido para cada equipo asignado.
- Guarda la asignación.
Asigna el ID de objeto del grupo de Entra a los equipos y roles de equipo de Apidog requeridos.
No hay un selector de rol de proyecto separado en la asignación de grupos SAML. El rol inicial del proyecto proviene del rol de equipo que se muestra en la tabla anterior. Ajusta el rol de proyecto de un usuario más tarde desde la configuración de miembros del proyecto cuando se requiera un acceso diferente.
Paso 4: Probar la asignación
Utiliza una cuenta de prueba en lugar de una cuenta de administrador.
- Confirma que el usuario de prueba pertenece al grupo de Entra asignado.
- Cierra sesión en Apidog.
- Inicia sesión a través del punto de entrada SSO de la organización.
- Abre el equipo asignado y confirma que está disponible.
- Verifica el rol de equipo del usuario.
- Abre los proyectos del equipo y confirma el rol inicial del proyecto.
Si el usuario ya tenía un rol de proyecto asignado manualmente, confirma que el rol permanece sin cambios después de otro inicio de sesión SSO.
Verificar la eliminación de membresía
La eliminación de grupos también debe probarse antes del lanzamiento.
- Elimina al usuario de prueba del grupo de Entra asignado.
- Permite que se complete el cambio del proveedor de identidad.
- Haz que el usuario inicie sesión a través de SSO nuevamente.
- Verifica la membresía del equipo correspondiente y las membresías del proyecto.
Cuando un usuario ya no está incluido en un grupo asignado, Apidog puede eliminar al usuario del equipo correspondiente durante la sincronización SAML. Si se elimina la membresía del equipo, también se eliminan las membresías del proyecto en ese equipo.
No utilices una cuenta de producción para la primera prueba de eliminación. Registra el resultado observado para tu configuración de identidad y procedimiento de baja.
Resolución de problemas
| Problema | Qué verificar |
|---|---|
| El usuario inicia sesión pero no es añadido al equipo | Confirma que la reclamación se llama exactamente groups, la aserción contiene el ID de objeto esperado y el ID de objeto en Apidog no tiene espacios adicionales. |
| La aserción no tiene valores de grupo | Confirma que el usuario pertenece al grupo y que la aplicación empresarial de Entra está enviando reclamaciones de grupo. Para usuarios con muchas membresías de grupo, revisa la guía de sobrecarga de reclamaciones de grupo de Microsoft. |
| El usuario tiene el rol de proyecto incorrecto | Verifica el rol del equipo asignado. Los roles de proyecto asignados existentes no se sobrescriben por la sincronización SAML posterior. |
| Un cambio de grupo no se refleja | Confirma que el cambio ha llegado a Entra, luego inicia un nuevo inicio de sesión SSO para que Apidog pueda sincronizar la aserción actual. |
| El usuario permanece en la organización | La asignación de grupos SAML gestiona el acceso al equipo asignado. La membresía de la organización también se puede gestionar a través de invitaciones, SSO o SCIM. |
Limitaciones importantes
- Apidog no crea ni elimina grupos de proveedores de identidad a través de SCIM.
- La asignación de grupos SAML no proporciona una configuración de rol separada para cada proyecto.
- Los roles de proyecto asignados existentes no se restablecen en inicios de sesión SSO posteriores.
- Si varias asignaciones pudieran aplicarse al mismo usuario y equipo, prueba el resultado antes del lanzamiento en lugar de asumir una regla de precedencia.
- Los roles del espacio de trabajo no autorizan llamadas a las API implementadas.
Tutoriales relacionados de gobernanza de API:
Estos tutoriales cubren controles complementarios para gobernar un espacio de trabajo de API empresarial:
- Marco de Gobernanza de API — conecta la propiedad, los controles, la evidencia y las decisiones del ciclo de vida.
- Asignación de Grupos SAML con Microsoft Entra ID — asigna acceso al equipo desde grupos de proveedores de identidad.
- Escáner de Secretos — revisa posibles credenciales expuestas en activos compatibles de Apidog.
- Registros de Auditoría — investiga y exporta la actividad administrativa de la organización.
- Aprovisionamiento SCIM — gestiona los usuarios de la organización a lo largo del ciclo de vida de la identidad.
- Políticas Empresariales — configura controles de credenciales, membresía, sesión SSO e invitación.
- Equipos de API de Auto-Servicio Gobernados — permite equipos creados por miembros mientras se mantiene la supervisión de la propiedad.
- Integración de GitHub Enterprise Cloud — conecta repositorios compatibles de GHE.com para flujos de trabajo de OpenAPI.
Documentación oficial relacionada: