Restringir quién puede entrar a través del proveedor de identidad

Decide a qué personas puede admitir el proveedor de identidad de tu tenant: concede un rol a una dirección de correo concreta o a todas las direcciones de un dominio de correo, y limita el inicio de sesión mediante el proveedor a los dominios que permitas.

Quién puede hacerlo

Un administrador del tenant o un administrador de acceso del tenant, o un superadministrador de plataforma que trabaja dentro de tu tenant.

• La sección Quién puede entrar a través de tu proveedor de identidad se muestra solo a quien puede leer tanto los proveedores (admin.tenant.idp.read) como las reglas de admisión (admin.tenant.idp.mapping.read).
• Agregar y eliminar una regla de correo o de dominio requiere el permiso para gestionar las asignaciones de federación (admin.tenant.idp.mapping.manage).
• Agregar y eliminar un dominio permitido requiere el permiso para configurar la federación de identidad (admin.tenant.idp.override).

Sin un permiso de escritura, las listas se muestran sin formulario para agregar una entrada y sin control para eliminarla.

En un despliegue SaaS, un operador de la plataforma que trabaja dentro de tu tenant con una sesión de acceso de soporte no puede agregar una regla de correo o de dominio, ni agregar o eliminar un dominio permitido. Lo hace el propio administrador de tu tenant.

Antes de empezar

• Tu tenant tiene declarado su propio proveedor de identidad. Consulta Iniciar sesión con el proveedor de identidad de tu empresa. Hasta que lo tenga, la sección dice Declara un proveedor antes de admitir usuarios por correo o dominio.
• Tres bloques, para dos preguntas distintas:
  • Correo a rol y Dominio a rol conceden un rol cuando hay coincidencia: una dirección completa, o todas las direcciones de un dominio.
  • Guardia de dominio no concede nada. Es una lista de permitidos por proveedor: un proveedor sin ningún dominio permitido deja pasar la guardia a todos los dominios; en cuanto tiene al menos uno, solo las identidades federadas cuyo dominio de correo está en su lista pueden completar el inicio de sesión. Por eso, el primer dominio permitido de un proveedor reduce quién puede entrar, cada uno adicional admite también su propio dominio, y eliminar el último vuelve a dejar pasar a todos los dominios que había excluido. Pasada la guardia, las reglas y las asignaciones de grupo siguen decidiendo quién se admite y con qué rol.
• Solo puedes agregar una regla para un rol si tú mismo tienes todos sus permisos, porque la regla confiere el rol a todas las personas con las que coincide.
• La lista de roles de Dominio a rol no ofrece ningún rol que lleve un permiso de plataforma o de comodín. La lista de roles de Correo a rol ofrece todos los roles que se pueden asignar a personas en tu tenant.
• Un valor de coincidencia o un dominio permitido no puede contener un comodín (*) ni caracteres de control.
• Agregar y eliminar piden un inicio de sesión reciente. Si el tuyo es demasiado antiguo, la consola te pide que confirmes quién eres antes de continuar.
• En un despliegue operado por el cliente, el operador de la plataforma debe haber delegado la federación de identidad a tu tenant.

Pasos

1. Abre Configuración y selecciona la pestaña Integraciones.
2. En la fila Federación de identidad, selecciona Gestionar.
3. Desplázate hasta Quién puede entrar a través de tu proveedor de identidad.
4. Para admitir una dirección, en Correo a rol elige el Proveedor, escribe la Dirección de correo, elige el Rol de ANKASecure y selecciona Agregar regla.
5. Para admitir a todas las direcciones de un dominio, en Dominio a rol elige el Proveedor, escribe el Dominio, elige el Rol de ANKASecure y selecciona Agregar regla.
6. Para limitar el inicio de sesión mediante un proveedor a los dominios que permitas, en Guardia de dominio elige el Proveedor, escribe el Dominio permitido y selecciona Agregar regla.
7. Para eliminar una entrada, selecciona el icono de papelera de su fila (Eliminar regla de correo, Eliminar regla de dominio o Eliminar dominio permitido). El diálogo del mismo título nombra la entrada; confirma con Eliminar regla de correo, Eliminar regla de dominio o Eliminar dominio permitido.

Qué ves cuando funcionó

La entrada aparece en la lista de su bloque, o sale de ella, y la consola confirma el cambio: Regla de correo agregada, Regla de dominio agregada, Dominio permitido agregado, o el mensaje correspondiente de eliminación (Regla de correo eliminada, Regla de dominio eliminada, Dominio permitido eliminado). Cada cambio se registra en la pista de auditoría y se aplica desde el siguiente inicio de sesión federado. Los dominios se guardan normalizados, así que Example-Bank.com y example-bank.com son el mismo dominio permitido.

Cuando la aprobación por quórum de tu tenant está activada y el rol admitido confiere derechos de aprobación, agregar la regla muestra En espera de aprobación con Abrir la solicitud de quórum: la regla no está en la lista hasta que tus aprobadores decidan.

Si falla

Una adición rechazada se muestra encima del formulario del bloque, con lo que escribiste todavía allí. Una eliminación rechazada se muestra dentro del diálogo, que sigue abierto.

Un rol que alguna regla todavía nombra no se puede eliminar: elimina primero la regla. Eliminar el proveedor elimina con él sus reglas y sus dominios permitidos.

Sin la consola

El cuerpo de una regla de admisión nombra el proveedor (idpConfigId), el ruleType (EMAIL o DOMAIN), el matchValue y el ankaRoleName; el de una guardia de dominio nombra el proveedor y el domain.

En un despliegue SaaS, createAdmissionRule, createDomainGuard y deleteDomainGuard llamados con una sesión de suplantación de acceso de soporte responden 403 impersonation-operation-forbidden.

Ningún comando de ankasecure-km ni método del Admin SDK gestiona las reglas de admisión ni las guardias de dominio.

Relacionado

• Configuración del Tenant: qué muestra la pantalla y cada decisión que tomas en ella.
• Asignar grupos del proveedor de identidad a roles
• Declarar los dominios de correo del tenant

Estas páginas están en inglés:

• Scope subset violation
• Federation not entitled
• Operation not available while impersonating