Federación de Identidad
Para qué sirve esta pantalla
Esta pantalla entrega el inicio de sesión de las personas a tu propio proveedor de identidad corporativo. Se abre desde Acceso e Identidad → Federación de Identidad y configura la conexión de todo el despliegue: el proveedor, qué grupos suyos y qué direcciones de correo corresponden a qué rol de ANKASecure, qué dominios de correo pueden completar un inicio de sesión, y una vista de solo lectura de la postura de federación del despliegue.
No es una lista de ajustes. Cinco de sus filas son valores del catálogo y todas son de solo lectura; todo lo que decides realmente aquí vive en las tablas de la plataforma y tiene su propio ciclo de declarar, probar y habilitar. La pestaña Configuración contiene ese ciclo; junto a ella, una pestaña Actividad muestra lo que se ha cambiado, si tienes un permiso de auditoría.
Hay una conexión por protocolo y un despliegue: tres ranuras — OIDC, SAML, LDAP — y como máximo un proveedor en cada una. Un tenant que opera su propio proveedor lo declara desde dentro de ese tenant, y por eso esta pantalla no tiene pestaña por tenant.
Qué debe existir antes
- El contexto de plataforma. Todo endpoint detrás de esta pantalla rechaza un token que no lleve el tenant de plataforma, siempre igual y sin decir por qué.
- El permiso de lectura de la configuración de proveedores de identidad, que llena las ranuras, los mapeos, las reglas de admisión y los dominios.
- El permiso de gestión de esa configuración, que la plataforma exige para toda escritura aquí, y también para Probar conexion y para la validación previa, porque ambas salen hacia tu proveedor en tu nombre. Todos los controles de esta pantalla, incluidos los mapeos de grupo a rol y las reglas de admisión, dependen de este mismo permiso; la escritura de la configuración de plataforma no interviene, y tenerla sin este deja los controles deshabilitados.
- Tu proveedor, alcanzable por HTTPS desde la plataforma y, para
LDAP, con una URLldaps://. Un enlace LDAP en claro se rechaza de plano.
Decisiones que tomas aquí
Declarar un proveedor
Una ranura vacía dice Sin configurar y ofrece Agregar proveedor OIDC, Agregar proveedor SAML o Agregar proveedor LDAP, que abre un asistente. Una ranura configurada muestra el protocolo, su estado vigente, un resumen de lo que importa en ese protocolo y las acciones Probar conexion, Editar, Habilitar, Deshabilitar y Eliminar. Deshabilitar pide un motivo; Eliminar te pide que escribas el protocolo (OIDC, SAML o LDAP) y que des un motivo. Ambos motivos son obligatorios y quedan registrados en la auditoría.
Declarar nunca habilita. Un proveedor recién declarado dice Aun no activable y no está delante de nadie hasta que lo habilitas explícitamente. El secreto que suministras es de solo escritura: nunca se devuelve, nunca se vuelve a mostrar y nunca se reenvía, así que editar un proveedor y guardar con el campo del secreto vacío conserva el que ya estaba.
Probar antes de habilitar
Probar conexion ejecuta desde dentro de la plataforma la misma comprobación que hará el inicio de sesión, y registra el veredicto. Es deliberadamente el mismo conjunto de comprobaciones, así que una prueba en verde predice un inicio de sesión que funciona.
Para OIDC descarga el documento de descubrimiento, rechaza un proveedor cuyo emisor anunciado no sea el que configuraste y luego contrasta los endpoints de autorización, de token y del conjunto de claves — y el opcional de cierre de sesión — con la lista de hosts permitidos de ese proveedor, antes de descargar el conjunto de claves.
Para SAML la prueba descarga los metadatos, los analiza de forma segura y comprueba que el primer certificado de firma esté vigente. Para LDAP se enlaza y hace una búsqueda superficial bajo el DN base, confiando en los certificados que configuraste en ese proveedor y no en el almacén de confianza predeterminado de la plataforma, y devuelve una muestra de los valores de grupo que vio.
Un fallo que la plataforma puede clasificar vuelve como un veredicto sobre el que puedes actuar, no como una caída genérica. Editar el proveedor borra el veredicto, así que un proveedor cuya configuración cambió después de una prueba superada vuelve a estar sin probar.
Habilitar
Habilitar se vuelve utilizable cuando la plataforma dice que el proveedor está listo, y la pantalla enumera lo que falta cuando no lo está. Se comprueban tres cosas: que la última prueba haya pasado con la configuración actual; que haya al menos un dominio de correo declarado; y, solo para OIDC, que hayas declarado si se confía en la verificación de correo de ese proveedor. Lo tercero es una decisión, no un trámite: dejarlo sin declarar no equivale a declarar que no se confía, y solo lo segundo cuenta como respuesta.
Aprobar un proveedor para el inicio de sesión en la plataforma
Un proveedor OIDC o SAML indica si está Aprobado para el inicio de sesión en la plataforma. Aprobarlo declara que el proveedor exige autenticación multifactor resistente al phishing a cada administrador de la plataforma que autentica. El diálogo muestra esa declaración, y Aprobar sigue deshabilitado hasta que la confirmas; la confirmación se registra con tu nombre y la hora.
Para los administradores de la plataforma, la aprobación es toda la decisión: la plataforma no añade ningún factor después de un proveedor aprobado y no evalúa cómo los autenticó. Retirar la aprobación hace que los administradores de la plataforma dejen de iniciar sesión mediante él; los miembros de los tenants siguen haciéndolo.
Los administradores de la plataforma solo inician sesión mediante proveedores aprobados, así que aprobar este proveedor es el primer paso cuando los administradores de la plataforma inician sesión mediante él. Necesita el permiso de gestionar la política de autenticación de la plataforma. Retirar el último proveedor aprobado se rechaza mientras los administradores de la plataforma inicien sesión solo mediante el proveedor de identidad.
Confiar en la autenticación multifactor del proveedor
Un proveedor OIDC o SAML indica también si se confía en su MFA: No confiar en la MFA de este proveedor, el valor predeterminado, o Confiar en la MFA de este proveedor. Decide cómo inicia sesión mediante él un administrador de un tenant, es decir, cualquier persona cuyos roles permiten un cambio. No afecta a los miembros que solo leen ni a los administradores de la plataforma.
Mientras no se confía en el proveedor, un administrador que inicia sesión mediante él confirma además con una clave de acceso o un código de su aplicación de autenticación, o añade uno. Mientras se confía, la plataforma pide la MFA al proveedor, y basta con su inicio de sesión cuando la prueba: el claim amr de OIDC o la clase de contexto de autenticación de SAML. Si no la prueba, se sigue pidiendo la clave o el código.
Elige Confiar en la MFA de este proveedor solo cuando el proveedor exija MFA a tus administradores y lo declare en su token o aserción. Mientras un administrador no tenga una clave o un código propios, cualquiera que tenga su contraseña en un proveedor no confiable puede añadir el primero, así que pídeles que registren uno pronto. En SAML, Clase de autenticación multifactor indica la clase que declara cuando no es https://refeds.org/profile/mfa; configura la clase que emite realmente, porque un proveedor al que se le pide una clase que no puede cumplir rechaza el inicio de sesión.
Editar lo que el proveedor puede afirmar, la clase incluida, lo devuelve a no confiable; márcalo como confiable de nuevo en una edición aparte. Con la aprobación por quórum activa, marcarlo como confiable espera a los aprobadores; retirar la confianza nunca espera. Un directorio LDAP no tiene esta opción.
Mapeo de grupo a rol y admisión por correo o dominio
El mapeo deniega por omisión. Una identidad federada que no resuelve a ningún rol se rechaza: no se crea cuenta y no se emite token. Dos ejes alimentan esa decisión y se combinan, no se ordenan por prioridad. Mapeo de grupo a rol asocia una cadena de grupo que emite tu proveedor a un rol de ANKASecure. Admision por correo y dominio asocia una dirección de correo completa, o un dominio, a un rol. Una coincidencia en cualquiera de los dos concede ese rol.
Un rol que no puedes asignar en el tenant de plataforma se rechaza en el momento de declararlo, en ambos ejes, con el motivo y las categorías permitidas.
Dominios verificados
En un despliegue que operas tú, declarar un dominio es verificarlo: no hay desafío DNS, ni token que publicar, ni estado pendiente. La plataforma te registra como quien lo declaró, tomándolo de tu sesión y no de nada que escribas. El flujo de dos partes en el que un tenant reclama un dominio y la plataforma lo confirma no se ofrece en una instalación operada por el cliente.
Solo se admite un inicio de sesión cuyo dominio de correo esté en este conjunto, comparado como igualdad exacta sobre el nombre normalizado y nunca como sufijo: acme.com no admite evil-acme.com, y tampoco admite mail.acme.com.
Las guardas de dominio son un control aparte y más estrecho en la misma pestaña. Donde las reglas de admisión conceden un rol, una guarda no concede nada: en cuanto un proveedor tiene al menos una guarda, solo las identidades cuyo dominio de correo esté en esa lista pueden terminar de iniciar sesión.
Eliminar un mapeo o una regla de admisión, o agregar una guarda de dominio, se rechaza cuando dejaría a la plataforma sin ningún superadministrador que pueda iniciar sesión, y no cambia nada. Un superadministrador vinculado al proveedor conserva esa forma de entrar mientras el dominio de su correo pase todas las guardas y una regla de correo o de dominio lo admita, o mientras el proveedor conserve al menos un mapeo de grupo: los grupos que envía tu proveedor solo se conocen cuando la persona inicia sesión, así que cualquier mapeo restante cuenta.
Postura
La última pestaña informa la postura de federación del despliegue y no se edita desde aquí: si a los proveedores LDAP se les rechaza un enlace en claro en producción, si el inicio de sesión único se impone a los tenants recién aprovisionados y si una identidad federada se aprovisiona en el primer inicio de sesión correcto.
Aquí se informa también el origen de borde que ve el navegador. La plataforma deriva de él, en el servidor, la URL de redirección de OAuth 2.0 y la URL del consumidor de aserciones de SAML, y por eso es de solo lectura en este plano: cambiarlo cambia la dirección a la que tu proveedor devuelve el navegador.
Cómo se relaciona con otras pantallas
Una identidad federada solo sirve cuando aterriza en una cuenta con roles. Ambas se administran en otro sitio, igual que la vinculación de una cuenta local existente con una identidad federada:
Las identidades de máquina son otro subsistema con otra pantalla: una carga de trabajo presenta un token que acuñó su propio emisor, y nada de esta página se le aplica:
Cómo inician sesión los administradores de la plataforma, y qué métodos de inicio de sesión puede admitir cada tenant, se decide en su propia pantalla:
El resto de la configuración de inicio de sesión — duración de tokens, bloqueo, cookies de sesión — es el grupo en el que vive esta pantalla, y el mapa de todos los sistemas externos a los que está conectado el despliegue:
Dónde leer más
Estas páginas están en inglés: