La Gestión Automatizada y los Controles de Acceso son funcionalidades independientes, pero generalmente se usan juntas. Consulte Controles de Acceso SAML para la guía complementaria.
Prerrequisitos
Antes de habilitar la gestión automatizada:- SAML SSO debe estar configurado y enviando atributos de metadatos al iniciar sesión
- La afirmación SAML debe incluir atributos estables para comparar
- Los equipos de destino ya deben existir en EKB; para instrucciones sobre cómo crear equipos, consulte Gestión de Equipos
Estructura de Reglas
Navegue a Super Admin → Users & Workspaces → Teams → Automated Management para configurar reglas. Cada regla incluye:| Campo | Requerido | Descripción |
|---|---|---|
| SAML Attribute Name | Sí | La clave del atributo de la afirmación SAML |
| Attribute Value(s) | Sí | Uno o más tokens separados por comas — todos los tokens listados deben coincidir (lógica AND) |
| Target Team | Sí | El equipo al que asignar al usuario |
| Default Team Membership Role | Opcional | Member (predeterminado) o Admin |
| Auto-add to team projects | Opcional | Agrega al usuario a todos los proyectos no predeterminados del equipo |
| Default Project Role | Opcional | Admin, Editor o Viewer |
| Forced continuous team reassignment | Opcional | Mueve usuarios en cada inicio de sesión, no solo en el primer inicio |
- Sobrescrituras Condicionales de Rol de Equipo — cambian el rol de membresía del equipo basándose en atributos SAML adicionales
- Sobrescrituras Condicionales de Rol de Proyecto — cambian el rol del proyecto basándose en atributos SAML adicionales (solo aplica cuando auto-add está activado)
Cómo Funciona la Coincidencia de Reglas
La coincidencia de atributos usa el mismo motor que los Controles de Acceso. Las reglas y los atributos de usuario se tratan ambos como conjuntos de tokens y se comparan con semántica de subconjunto — una regla coincide cuando sus tokens requeridos son un subconjunto de los tokens del usuario.- Las comas en Valor(es) de Atributo son separadores de tokens.
Accounting, USrequiere que el usuario tenga ambos tokens (lógica AND dentro de una regla). - Especificidad iguala el número de tokens que requiere una regla. Cuando múltiples reglas coinciden, la más específica (más tokens) gana.
Manejo de diferentes formatos de transmisión SAML
Los atributos SAML pueden llegar en dos formatos, y cada regla expone un toggle para manejarlos: Multi-valor nativo — el IdP envía múltiples elementos<AttributeValue>. EKB siempre trata esto como un conjunto automáticamente.
Valor único con CSV — el IdP empaqueta valores en una sola cadena separada por comas. Use el toggle por regla:
| Toggle: “IdP packs multi-values into one string” | Comportamiento |
|---|---|
| Off (predeterminado) | La cadena del usuario se trata como un token literal |
| On | La cadena del usuario se divide por comas y se compara como un conjunto |
Comportamiento de Asignación de Equipo
En cada inicio de sesión SSO, EKB evalúa las reglas configuradas contra los metadatos SAML del usuario y selecciona la regla coincidente más específica.| Estado del Usuario | Resultado |
|---|---|
| Sin equipo aún | Asignado al equipo de destino |
| Ya en el equipo de destino | Sin cambio |
| En un equipo diferente | Movido solo si Forced continuous team reassignment está activo |
| Propietario de un equipo con múltiples miembros | No se mueve forzadamente (previene propiedad huérfana) |
| Único miembro/propietario de su equipo | Movido; el equipo ahora vacío se elimina |
Para la incorporación初次初次 de SSO, la reasignación siempre se fuerza para establecer la colocación correcta.
Rol de Membresía del Equipo
El rol con el que se agrega un usuario a un equipo se resuelve en este orden:- Sobrescritura Condicional de Rol de Equipo — la sobrescritura más específica en la regla coincidente cuyos tokens son subconjunto de los del usuario
- Rol Predeterminado de Membresía del Equipo —
MemberoAdminsegún se configura en la regla (predeterminado heredado:Member)
Los roles de equipo se aplican solo al momento de agregar. Si un usuario ya está en el equipo de destino, su rol existente se preserva — los inicios de sesión subsiguientes no lo cambiarán. Promover o degradar un miembro existente requiere una acción explícita del administrador.
Sobrescrituras Condicionales de Rol de Equipo
Cada sobrescritura especifica un Nombre de Atributo, Valor(es) de Atributo, el toggle opcionalis_csv_value y un Rol de Equipo (Member o Admin). La sobrescritura coincidente más específica gana; los empates generan un registro de advertencia.
Auto-Agregar a Proyectos
Cuando Auto-add to team projects está habilitado en una regla, EKB agrega al usuario a proyectos no predeterminados en el equipo de destino. El usuario solo se agrega a proyectos del que aún no sea miembro. Prioridad de asignación de roles:- Sobrescritura Condicional de Rol de Proyecto coincidente (coincidencia más específica)
- Rol Predeterminado de Proyecto definido en la regla del equipo
La asignación de proyectos se ejecuta de forma asíncrona. La membresía del equipo puede aparecer antes de que se completen todas las membresías de proyecto.
Los roles de proyecto se aplican solo al momento de agregar. Las membresías de proyecto existentes nunca se re-evalúan ni cambian en inicios de sesión subsiguientes.
Sobrescrituras Condicionales de Rol de Proyecto
Las sobrescrituras de rol permiten asignar un rol de proyecto diferente basándose en atributos SAML adicionales. Ejemplo:- Regla de equipo:
department = engineering, rol predeterminado →Viewer - Sobrescritura de rol:
level = manager→Admin
- Todos los usuarios de
engineeringse agregan al equipo - Los usuarios que también tienen
level = managerrecibenAdminen proyectos auto-agregados - Los que no son managers mantienen
Viewer
Si múltiples sobrescrituras condicionales de rol podrían coincidir con el mismo usuario, la más específica (más tokens) gana. Los empates generan un registro de advertencia y recurren a la sobrescritura creada primero — reestructure las sobrescrituras para evitar empates.
Restricciones de Reasignación de Equipo
Se encuentran en Super Admin → Teams → Automated Management → Team Reassignment Restrictions, estas configuraciones control qué sucede con las membresías de proyecto cuando un usuario se mueve entre equipos. Las tres están predeterminadas en off (no destructivo).
| Configuración | Descripción |
|---|---|
| 1. Remove user from old team’s projects | Interruptor maestro. Elimina membresías de proyecto antiguas en la reasignación. |
| 2. Projects owned by user follow them | Depende de la configuración 1. Los proyectos propios se mueven al nuevo equipo. |
| 3. Remove old team members from followed projects | Depende de las configuraciones 1 y 2. Limpia el acceso del equipo antiguo en proyectos movidos. |
- Solo configuración 1 — el usuario se elimina de los proyectos del equipo antiguo; los proyectos propios permanecen en el equipo antiguo y la propiedad se transfiere al propietario del equipo antiguo
- Configuraciones 1 + 2 — los proyectos que posee el usuario se mueven al nuevo equipo; los miembros existentes de esos proyectos se mantienen en su lugar
- Configuraciones 1 + 2 + 3 — los miembros del equipo antiguo también se eliminan de los proyectos que se movieron con el propietario
Configurar Reglas de Gestión Automatizada
Abrir Gestión Automatizada
Vaya a Super Admin → Users & Workspaces → Teams → Automated Management y haga clic en Add Rule.
Ingresar criterios de coincidencia SAML
Proporcione el SAML Attribute Name, Attribute Value(s) y Target Team.Para reglas con múltiples tokens, escriba cada token y presione coma para crear un chip (por ejemplo, 
accounting + us para requerir ambos). Active IdP packs multi-values into one string si es necesario.Establecer rol de membresía del equipo
Elija un Default Team Membership Role (
Member o Admin) y opcionalmente agregue Sobrescrituras Condicionales de Rol de Equipo para usuarios que deban recibir un rol de equipo diferente basándose en atributos adicionales.Configurar opciones adicionales
Decida si habilitar Auto-add to team projects y/o Forced continuous team reassignment.
Establecer rol de proyecto (si auto-add está habilitado)
Elija un Default Project Role y opcionalmente agregue Sobrescrituras Condicionales de Rol de Proyecto.
Guardar y configurar restricciones de reasignación
Guarde la regla, luego opcionalmente configure Team Reassignment Restrictions para definir el comportamiento cuando los usuarios cambien de equipo.
Mejores Prácticas de Diseño de Reglas
- Use atributos estables del proveedor de identidad — evite valores volátiles o que cambien frecuentemente
- Mantenga los nombres de atributos consistentes con los nombres exactos de las reclamaciones SAML (con distinción de mayúsculas/minúsculas a nivel de reclamación en algunos IdPs)
- Prefiera atributos SAML multi-valor nativos cuando su IdP los admita — son inequívocos y no requieren el toggle
is_csv_value - Evite reglas superpuestas con la misma especificidad — si ve una advertencia de “Ambiguous match”, agregue más tokens a una regla para que sea estrictamente más específica
- Comience con mínimo privilegio (rol de equipo
Member, rol de proyectoViewer) y eleve solo donde sea necesario a través de sobrescrituras condicionales - Documente la propiedad de las reglas y programe revisiones periódicas
Lista de Verificación de Pruebas
Después de la configuración, verifique cada escenario:- Los usuarios permitidos se colocan en el equipo correcto con el rol de equipo correcto
- Las sobrescrituras condicionales de rol de equipo se aplican a los usuarios correctos
- El auto-agregado a proyectos se completa con el rol correcto (permita unos segundos para el procesamiento asíncrono)
- Las sobrescrituras condicionales de rol de proyecto se aplican a los usuarios correctos
- La reasignación forzada funciona como se esperaba (si está habilitada)
- Las configuraciones de restricción de reasignación se comportan correctamente durante el movimiento entre equipos
Solución de Problemas
El usuario inició sesión pero no se asignó al equipo esperado
El usuario inició sesión pero no se asignó al equipo esperado
- Confirme que exista una regla de asignación de equipo coincidente
- Confirme que el equipo de destino aún exista
- Verifique que los tokens de atributo/valor de la regla sean un subconjunto de los metadatos SAML reales del usuario (verifique la vista de usuarios del Super Admin)
- Habilite Forced continuous team reassignment si el usuario ya pertenece a otro equipo y debe ser movido
- Si el usuario es propietario de un equipo con múltiples miembros, no será movido automáticamente — esto es intencional
- Si los registros contienen una advertencia de
Ambiguous match, dos reglas empataron con la misma especificidad; reestructure para eliminar la superposición
El usuario se asignó al equipo pero con el rol de equipo incorrecto
El usuario se asignó al equipo pero con el rol de equipo incorrecto
- Verifique si existe una Sobrescritura Condicional de Rol de Equipo y si coincide con el usuario
- Los roles de equipo se aplican solo al momento de agregar — si el usuario ya estaba en el equipo antes de que se agregara la sobrescritura, su rol existente se preserva; promuévalo o degradélo manualmente
- Para empates entre sobrescrituras, verifique los registros y agregue más tokens a la sobrescritura deseada para que sea estrictamente más específica
El usuario se asignó al equipo pero no a los proyectos
El usuario se asignó al equipo pero no a los proyectos
- Confirme que Auto-add to team projects esté habilitado en la regla coincidente
- Confirme que el equipo tenga proyectos no predeterminados
- Confirme que se haya establecido un rol de proyecto válido (
Admin,EditoroViewer) - Permita un breve retraso para el procesamiento asíncrono en segundo plano
La sobrescritura de rol no se aplicó
La sobrescritura de rol no se aplicó
- Confirme que la sobrescritura de rol esté adjunta a la regla de asignación de equipo correcta
- Confirme que el atributo/valor adicional realmente exista en los metadatos SAML del usuario
- Si se está aplicando el rol predeterminado, ninguna sobrescritura condicional coincidió
- Si el atributo llega como una cadena CSV única, confirme que IdP packs multi-values into one string esté habilitado en la sobrescritura
Advertencia de "Ambiguous match" en registros
Advertencia de "Ambiguous match" en registros
Dos o más reglas (o sobrescrituras) de igual especificidad coincidieron con el mismo usuario. EKB seleccionó determinísticamente la creada primero, pero la configuración es frágil.La línea de registro lista los IDs de las reglas empatadas. Edite una para agregar más tokens requeridos de modo que sea estrictamente más específica, o elimine la superposición por completo.
Guía Operativa
- Trate las reglas de asignación como configuración sensible de seguridad
- Use procesos de gestión de cambios para actualizaciones en producción
- Vuelva a probar después de cualquier cambio en las reclamaciones del IdP (por ejemplo, cambiar de CSV a multi-valor nativo, o renombrar una reclamación)
- Revise periódicamente las reglas y elimine mapeos obsoletos
- Inspeccione los metadatos SAML almacenados en la vista de usuarios del Super Admin antes de crear nuevas reglas