Tipos de protocolos de inicio de sesión único

El inicio de sesión único (SSO) permite que un usuario use un conjunto único de credenciales de inicio de sesión, como un nombre de usuario y una contraseña, o incluso la autenticación de múltiples factores, para acceder a múltiples aplicaciones. Esta es una arquitectura de administración de identidad federada, a veces denominada federación de identidad. Para que SSO funcione, la mayoría de las aplicaciones se basan en protocolos estándar abiertos para definir cómo los proveedores de servicios (SP) y los proveedores de identidad (IdP) pueden intercambiar información de identidad y autenticación entre sí.

Para obtener más información sobre cómo funciona SSO y los beneficios de uno de los protocolos más comunes, SAML.

Para integrar a la perfección todas las aplicaciones, la solución de inicio de sesión único de PortalGuard admite muchos tipos de protocolos SSO, que incluyen:

Servicio de autenticación central (CAS)

Desarrollado por Shawn Bayern en la Universidad de Yale, CAS se diferencia del SAML SSO típico al promulgar la comunicación de servidor a servidor. La máquina del cliente se usa para iniciar la solicitud del token, pero la verificación final la maneja una comunicación de back-end entre el servidor CAS y el proveedor de servicios. CAS es un protocolo SSO típico utilizado en instituciones educativas debido a la confianza en esa verificación adicional más directa. Al igual que SAML, no se intercambian contraseñas a través del token SSO.  

CAS es un protocolo SSO común para la educación superior. Consulta la página SSO para educación para obtener más detalles.

Shibboleth SSO

Shibboleth es otro protocolo de SSO que suele verse en instituciones educativas, específicamente donde un gran número están federadas para compartir aplicaciones y/o servicios. Shibboleth está construido con SAML como base, pero usa Discovery Service para mejorar la organización de datos de SAML de una gran cantidad de fuentes. Además, Shibboleth ayuda a automatizar el análisis de metadatos para manejar actualizaciones de certificados de seguridad y otras configuraciones que pueden establecer instituciones individuales dentro de una federación.  

SSO basado en cookies

Funciona mediante el uso de cookies HTTP basadas en la web para transportar las credenciales del usuario desde el navegador al servidor sin la intervención del usuario. Las credenciales existentes en la máquina del cliente se recopilan y cifran antes de almacenarse en la cookie y enviarse al servidor de destino. El servidor recibe la cookie, extrae y descifra las credenciales y las valida contra el directorio interno de usuarios del servidor.  

SSO basado en notificaciones

Los reclamos (también conocidos como «afirmaciones») son creados por un emisor de reclamos en el que confían varias partes. Los reclamos generalmente se empaquetan en un token firmado digitalmente que se puede enviar a través de la red utilizando el lenguaje de marcado de aserción de seguridad (SAML).  

SSO basado en NTLM

Es posible que un usuario demuestre que conoce su contraseña sin proporcionar la contraseña en sí. NTLM logra esto mediante un protocolo de desafío y respuesta que primero determina qué tipo de NTLM y mecanismos de encriptación admiten mutuamente el cliente y el servidor, luego codifica criptográficamente la contraseña del usuario y la envía al servidor que requiere autenticación.   

SSO basado en Kerberos

Kerberos permite a los usuarios iniciar sesión en tus cuentas de dominio de Windows y luego recibir SSO en aplicaciones internas. Kerberos requiere que el usuario tenga conectividad con un Centro de distribución de claves (KDC) central. En Windows, cada controlador de dominio de Active Directory actúa como un KDC. Los usuarios se autentican en los servicios (por ejemplo, servidores web) autenticándose primero en el KDC y luego solicitando tickets de servicio encriptados del KDC para el servicio específico que desean usar. Esto sucede automáticamente en todos los principales navegadores que usan SPNEGO (ver más abajo).  

SSO basado en SPNEGO

Hay instancias en las que la aplicación cliente y el servidor remoto no saben qué tipos de autenticación el otro admite. Aquí es cuando se puede utilizar SPNEGO (Mecanismo de negociación GSSAPI simple y protegido) para averiguar qué mecanismos de autenticación están disponibles mutuamente. Algunos de estos mecanismos pueden incluir autenticación Kerberos y NTLM.  

SSO reducido

El inicio de sesión único reducido se usa ampliamente para limitar la cantidad de veces que se requerirá que un usuario ingrese sus credenciales para acceder a diferentes aplicaciones. Con las aplicaciones críticas, el SSO reducido también ofrece una técnica para garantizar que un usuario no inicie sesión sin un segundo factor de autenticación proporcionado por el usuario.  

SSO basado en inscripción

Un usuario que inicia sesión en un sitio web puede optar por que sus credenciales se recuerden de forma permanente para ese sitio. Esto se logra mediante la creación de una cookie cifrada en la máquina del usuario para ese navegador web que contiene las credenciales del usuario. Esta cookie persiste en diferentes sesiones del navegador y reinicia la máquina, pero se configurará para que caduque después de un período determinado. La próxima vez que el usuario accede al sitio web, el servidor reconoce la cookie, la descifra para obtener las credenciales del usuario y omite por completo la pantalla de inicio de sesión después de validarlas con éxito.  

SSO de cumplimentación de formulario

La cumplimentación de formularios permite el almacenamiento seguro de información que normalmente se llena en un formulario. Para los usuarios que completan formularios repetidamente (especialmente para el acceso de seguridad), esta tecnología recordará/almacenará toda la información relevante y la protegerá con una única contraseña. Para acceder a la información, el usuario solo tiene que recordar una contraseña y la tecnología Form-filling puede encargarse de llenar en los formularios. 

Banner XE/Banner 9

Banner XE/Banner 9 soporta CAS SSO. Si bien no es el protocolo SSO más nuevo, CAS SSO mejora la usabilidad de Banner. Además, CAS SSO aumenta simultáneamente los puntos de integración de Banner en varias instituciones. Las instituciones de educación superior que buscan opciones adicionales y más viables pueden optar por usar Banner XE/Banner 9 para llenar el vacío. CAS SSO abre Banner XE/Banner 9 a configuraciones e implementaciones más exclusivas.

Mira el inicio de sesión único de PortalGuard en acción

Disfruta esta breve demo de Inicio de sesión único con las pcapacidades de PortalGuard y luego regístrate a nuestra prueba gratuita ppara probarlo.