Saltar al contenido principal
Cuando un usuario inicia sesión a través de SAML SSO, EKB recibe atributos de metadatos SAML (por ejemplo, department, group o role). La funcionalidad de Controles de Acceso usa esos atributos para determinar si se permite a un usuario entrar a la aplicación.
Los Controles de Acceso y la Gestión Automatizada de Equipos son funcionalidades independientes, pero generalmente se usan juntas. Consulte Asignación Automatizada de Equipos y Proyectos para la guía complementaria.

​
Prerrequisitos

Antes de habilitar los controles de acceso:
  • SAML SSO debe estar configurado y enviar atributos de metadatos al iniciar sesión
  • La afirmación SAML debe incluir atributos estables para comparar
Valide los nombres y valores de los atributos de algunos inicios de sesión SAML exitosos antes de habilitar cualquier restricción. La vista de usuarios del Super Admin muestra los metadatos SAML almacenados para cada usuario SSO — use esto como fuente de verdad al crear reglas.

​
Modos de Acceso

Navegue a Super Admin → Security & Access → Access Controls para seleccionar un modo. Selección de Modo de Acceso
ModoComportamiento
Allow Any New UsersPredeterminado. Se permiten registros por correo electrónico/contraseña, Google OAuth y SSO.
Restrict to SAML MetadataSolo se permiten usuarios SSO cuyos atributos SAML coincidan con al menos una regla configurada.

​
Cómo Funciona la Coincidencia de Reglas

Las reglas se definen por un Nombre de Atributo y uno o más Valores de Atributo. Reglas de Acceso SAML

​
El modelo mental: todo es un conjunto

Una regla y un atributo de usuario entrante se reducen ambos a un conjunto 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
  • La lógica entre reglas es OR — cualquier coincidencia individual de regla otorga acceso
  • Todas las comparaciones son sin distinción de mayúsculas/minúsculas e ignoran espacios al inicio/final

​
Reglas con múltiples tokens (AND dentro de una regla)

Las comas en el campo Valor(es) de Atributo son separadores de tokens. La interfaz promueve cada entrada separada por comas en un chip; la regla requiere que todos los tokens listados estén presentes.
  • engineering — requiere un token: el atributo del usuario debe contener engineering
  • Accounting, US — requiere dos tokens: el atributo del usuario debe contener ambos accounting y us

​
Manejo de diferentes formatos de transmisión SAML

Los atributos SAML pueden llegar en dos formatos: Multi-valor nativo — el IdP envía múltiples elementos <AttributeValue> dentro de un <Attribute>: 
<Attribute Name="memberOf">
  <AttributeValue>Accounting</AttributeValue>
  <AttributeValue>US</AttributeValue>
</Attribute>
EKB siempre trata esto como un conjunto. No se necesita configuración adicional. Este es el formato preferido. Valor único con CSV — el IdP envía un <AttributeValue> que contiene tokens separados por comas: 
<Attribute Name="memberOf">
  <AttributeValue>Accounting,US</AttributeValue>
</Attribute>
Esto es ambiguo (¿son dos grupos, o un valor literal que contiene una coma?). Use el toggle por regla para resolverlo:
Toggle: “IdP packs multi-values into one string”Comportamiento
Off (predeterminado)La cadena del usuario se trata como un token literal
OnLa cadena del usuario se divide por comas y se compara como un conjunto
Este toggle solo afecta cómo se interpreta el atributo del usuario. Las comas en el lado de la regla siempre son separadores de tokens sin importar la configuración.

​
Matriz de comportamiento de coincidencia

Atributo del usuario (formato)ToggleValor de regla¿Coincide?
nativo ["A","B","C"]offA✓
nativo ["A","B","C"]offA, B✓
único "A,B,C"offA✗
único "A,B,C"offA, B✗
único "A,B,C"onA✓
único "A,B,C"onA, B✓
único "A"offA✓

​
Comportamiento Cuando el Modo Restringido está Activo

  • Nuevos registros por correo electrónico/contraseña
  • Nuevos registros por Google OAuth
  • Nuevos usuarios SSO cuyos atributos SAML no coincidan con ninguna regla
  • Usuarios SSO existentes que coincidan con al menos una regla (se re-verifica en cada inicio de sesión)
  • Usuarios locales existentes iniciando sesión en cuentas existentes
  • Cuentas de Super Admin a través de SSO, incluso sin una regla coincidente (escapatoria intencional)
  • Claves API pertenecientes a Super Admins o claves a nivel de proyecto sin fila de usuario asociada
Las solicitudes de claves API de usuarios vinculados a SAML también se controlan en modo restringido. EKB verifica los metadatos SAML almacenados del usuario (de su último inicio de sesión SSO) contra las reglas de acceso antes de permitir acceso a la API.
Comportamiento de apertura por fallo: Si el modo restringido está activado pero no existen reglas de acceso SAML, EKB permite a todos los usuarios SSO. Esto previene el bloqueo accidental, pero siempre debe definir al menos una regla antes de habilitar la gobernanza estricta.

​
Configurar Controles de Acceso

1

Abrir Controles de Acceso

Vaya a Super Admin → Security & Access → Access Controls.
2

Seleccionar Modo Restringido

Elija Restrict to SAML Metadata.
3

Agregar Reglas de Acceso SAML

Agregue una o más reglas bajo SAML Access Rules. Ejemplos:
department = engineering
memberOf = ekb-users
memberOf = ekb-users, us   (requiere ambos tokens)
Active el toggle IdP packs multi-values into one string si el atributo del lado del usuario llega como una sola cadena separada por comas.
4

Guardar y Validar

Guarde sus reglas y pruebe con cuentas SSO representativas antes de implementar ampliamente.

​
Enfoque de Implementación Recomendado

  1. Cree reglas mientras el modo sigue establecido en Allow Any New Users
  2. Valide inspeccionando los metadatos SAML almacenados para cuentas SSO piloto en la vista de usuarios del Super Admin
  3. Cambie a Restrict to SAML Metadata
  4. Monitoree los inicios de sesión y los resultados de acceso denegado

​
Lista de Verificación de Pruebas

Después de la configuración, verifique cada escenario:
  • Un usuario SSO que debe ser permitido puede iniciar sesión
  • Un usuario SSO que no debe ser permitido es redirigido a la experiencia de acceso denegado
  • Los usuarios denegados ven la experiencia de acceso denegado esperada
  • Al menos una regla válida está activa para evitar deriva de políticas

​
Solución de Problemas

  • Confirme que el modo de acceso no esté establecido accidentalmente como restringido
  • Verifique que la regla use el nombre de atributo correcto y el valor exacto esperado
  • Confirme que el IdP esté enviando ese atributo para ese usuario
  • Para reglas con múltiples tokens, cada token listado debe estar presente en el atributo del usuario — verifique los metadatos SAML almacenados en la vista de usuarios del Super Admin
  • Si el atributo llega como una cadena CSV única, confirme que IdP packs multi-values into one string esté habilitado en la regla
  • Verifique si el usuario está intentando iniciar sesión con correo electrónico/contraseña o Google OAuth mientras el modo restringido está activo
Las cuentas de Super Admin siempre son permitidas a través de SSO incluso sin una regla coincidente. Si está bloqueado, inicie sesión a través de SSO usando una cuenta de Super Admin para recuperar el acceso.

​
Guía Operativa

  • Trate las reglas de acceso 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
  • Revise periódicamente las reglas y elimine mapeos obsoletos
  • Mantenga al menos una regla válida activa para prevenir estados de apertura por fallo no deseados