¿Qué es un proveedor de identidad (IdP)?

Un proveedor de identidad (IdP) es un servicio externo —como Okta, Microsoft ADFS, Azure AD, OneLogin o Ping Identity— que autentica a los usuarios y emite aserciones firmadas que confirman su identidad. Un proveedor de servicios, como el inicio de sesión en Versa Director o Concerto, confía en dichas aserciones para conceder o denegar el acceso sin gestionar directamente las credenciales de los usuarios.

Puntos clave

• Los IdP autentican a los usuarios y emiten afirmaciones firmadas a los proveedores de servicios.
• SAML y OpenID Connect son los dos formatos estándar de aserción.
• Los flujos de inicio de sesión SSO son el iniciado por el SP y el iniciado por el IdP.
• Versa Tanto Director como Concerto y el proxy inverso de aplicaciones utilizan aserciones del IdP.
• Entre los proveedores de identidad (IdP) más habituales se encuentran Okta, Azure AD, ADFS, OneLogin y Ping Identity.

En esta página: Por qué es importante · Cómo funciona · Tipos · IdP y Versa · Preguntas frecuentes

¿Por qué es importante un IdP?

Cada aplicación que utiliza un usuario —Director, Concerto, una herramienta SaaS, una aplicación web interna— necesita saber quién es ese usuario. Sin un proveedor de identidad compartido, cada servicio gestiona su propio almacén de contraseñas, y cada nueva contratación o baja implica actualizar las credenciales en sistemas inconexos, lo que supone un riesgo: cuentas obsoletas, contraseñas débiles y la ausencia de un punto único desde el que aplicar la autenticación multifactorial (MFA) o revocar el acceso al instante.

En cambio, un IdP centraliza la autenticación. Los usuarios se autentican una sola vez, y el IdP avala su identidad ante todos los servicios que confían en él; un proveedor de servicios como Director nunca ve ni almacena la contraseña. Esa centralización permite aplicar la autenticación multifactorial (MFA) y las comprobaciones del estado de los dispositivos desde un único punto, y convierte al IdP en el primer punto de control del modelo Zero Trust: el proxy inverso y las pasarelas ZTNA se basan en su verificación antes de conceder el acceso.

¿Qué es un IdP?

Un IdP es la parte de un intercambio de autenticación que verifica las credenciales de un usuario y emite una afirmación firmada que confirma su identidad y, a menudo, los atributos que le corresponden (función, organización, grupo). Su contraparte es el proveedor de servicios (SP), que confía en la firma y nunca gestiona la contraseña directamente.

Hay dos estándares que regulan este intercambio. SAML es un formato basado en XML en el que el IdP y el SP intercambian metadatos por adelantado, y el IdP devuelve una aserción tras la autenticación. OpenID Connect, basado en OAuth 2.0, utiliza un token web JSON y se adapta a las integraciones «API-first». Ambos pueden funcionar con inicio por parte del SP (el usuario comienza en la aplicación y es redirigido al IdP) o con inicio por parte del IdP (el usuario ya está autenticado en el portal del IdP).

El certificado de firma del IdP y la sincronización del reloj con cada SP conectado garantizan la validez de la cadena.

Tipos de proveedores de identidad (IdP)

Los IdP se clasifican en varias categorías. Los IdP alojados en la nube —Okta, Microsoft Entra ID (Azure AD), OneLogin, Ping Identity— funcionan como SaaS gestionado; la organización configura a los usuarios a través de la consola del proveedor, y el IdP se encarga del tiempo de actividad y la rotación de certificados. Los IdP locales, como los Servicios de federación de Active Directory (ADFS), se ejecutan dentro de la propia infraestructura de la organización, a cambio de lo cual se renuncia a esa comodidad a cambio de un mayor control sobre la residencia de los datos y la integración de directorios.

Un segundo eje es la compatibilidad con protocolos: algunos IdP solo admiten SAML, otros solo OpenID Connect, y la mayoría de los IdP de nivel empresarial —incluidos los cinco probados con Director y Concerto— admiten ambos. Un tercer patrón es el IdP intermediario, que se federa con IdP de nivel superior; el proxy inverso de aplicaciones de Versautiliza este patrón, situándose entre un proveedor de SaaS y el IdP real para que se puedan aplicar las políticas en ese punto intermedio.

IdP y Versa

Tanto Director como Concerto autentican a los administradores a través de un proveedor de identidad (IdP) externo, en lugar de cuentas locales o junto con ellas. Configurar el inicio de sesión único en Director o en Concerto implica cargar el archivo XML de metadatos del IdP, introducir el ID de entidad del SP y la URL de ACS, y asignar los atributos SAML u OpenID Connect a los roles. Ambos admiten flujos iniciados por el SP y por el IdP, y han sido probados con Okta, ADFS, Azure AD, OneLogin y Ping Identity.

El modelo se extiende a los usuarios finales. El proxy inverso de aplicaciones permite que Versa actúe como intermediario de IdP frente a aplicaciones SaaS (Box, Dropbox, Salesforce, Office) y aplicaciones web privadas, SSH o RDP: el IdP real autentica al usuario, envía una aserción SAML a Versa y, solo entonces, el proxy inverso concede el acceso, aplicando ZTNA, SWG, CASB y DLP en la misma ruta.

Preguntas frecuentes

¿Cuál es la diferencia entre un IdP y un proveedor de servicios (SP)?

El IdP autentica al usuario y emite una aserción firmada; el SP es la aplicación a la que el usuario intenta acceder, y esta confía en dicha aserción en lugar de gestionar la contraseña por sí misma. Director y Concerto actúan como proveedores de servicios cuando se configuran para el inicio de sesión único (SSO).

¿Cuál es la diferencia entre SAML y OpenID Connect?

SAML es un estándar más antiguo basado en XML que permite el intercambio de aserciones firmadas entre un proveedor de identidades (IdP) y un proveedor de servicios (SP), muy utilizado en el inicio de sesión único (SSO) empresarial. OpenID Connect, basado en OAuth 2.0, utiliza en su lugar tokens web JSON y se adapta mejor a las integraciones web modernas y al enfoque «API-first». Director y Concerto son compatibles con ambos estándares.

¿Cuál es la diferencia entre el SSO iniciado por el SP y el iniciado por el IdP?

El SSO iniciado por el SP comienza cuando un usuario hace clic en un enlace de inicio de sesión de la aplicación, lo que le redirige al IdP para su autenticación. El SSO iniciado por el IdP comienza en el propio portal del IdP, redirigiendo a un usuario ya autenticado directamente a la aplicación, sin que sea necesario hacer clic en ningún enlace de inicio de sesión.

¿Puede una organización utilizar más de un proveedor de identidad (IdP)?

Sí. Director es compatible con múltiples conectores de SSO, y el proxy inverso de aplicaciones puede actuar como interfaz para múltiples aplicaciones SaaS y privadas, cada una de las cuales apunta a un proveedor de identidad (IdP) o perfil de autenticación diferente, lo que permite a una organización combinar proveedores de identidad en la nube y locales, siempre que resulte conveniente.

¿Sustituye un IdP a las cuentas de usuario locales?

No necesariamente. Director y Concerto admiten tanto la autenticación basada en un proveedor de identidades (IdP) como la autenticación local de forma simultánea, por lo que los administradores pueden mantener una cuenta local de acceso de emergencia mientras que la mayoría de los usuarios se autentican a través del inicio de sesión único (SSO); esto sirve como plan de contingencia en caso de que el propio IdP quede inaccesible, no responda o esté mal configurado.

Más información sobre IdP

Si quieres saber más, estas son algunas fuentes en las que confiamos.

Términos relacionados

Si estás leyendo sobre IdP, te conviene echar un vistazo a lo siguiente.