El inicio de sesi\u00f3n \u00fanico (SSO) permite que un usuario use un conjunto \u00fanico de credenciales de inicio de sesi\u00f3n, como un nombre de usuario y una contrase\u00f1a, o incluso la autenticaci\u00f3n de m\u00faltiples factores, para acceder a m\u00faltiples aplicaciones. Esta es una arquitectura de administraci\u00f3n de identidad federada, a veces denominada federaci\u00f3n de identidad. Para que SSO funcione, la mayor\u00eda de las aplicaciones se basan en protocolos est\u00e1ndar abiertos para definir c\u00f3mo los proveedores de servicios (SP) y los proveedores de identidad (IdP) pueden intercambiar informaci\u00f3n de identidad y autenticaci\u00f3n entre s\u00ed.<\/p>\n\n\n\n
Para obtener m\u00e1s informaci\u00f3n sobre c\u00f3mo funciona SSO y los beneficios de uno de los protocolos m\u00e1s comunes, SAML, visita nuestra p\u00e1gina de inicio de sesi\u00f3n \u00fanico SAML<\/a>.<\/p>\n\n\n\n Para integrar a la perfecci\u00f3n todas las aplicaciones, la soluci\u00f3n de inicio de sesi\u00f3n \u00fanico de PortalGuard<\/a> admite muchos tipos de protocolos SSO, que incluyen: <\/p>\n\n\n\n Desarrollado por Shawn Bayern en la Universidad de Yale, CAS se diferencia del SAML SSO t\u00edpico al promulgar la comunicaci\u00f3n de servidor a servidor. La m\u00e1quina del cliente se usa para iniciar la solicitud del token, pero la verificaci\u00f3n final la maneja una comunicaci\u00f3n de back-end entre el servidor CAS y el proveedor de servicios. CAS es un protocolo SSO t\u00edpico utilizado en instituciones educativas debido a la confianza en esa verificaci\u00f3n adicional m\u00e1s directa. Al igual que SAML, no se intercambian contrase\u00f1as a trav\u00e9s del token SSO. <\/p>\n\n\n\n CAS es un protocolo SSO com\u00fan para la educaci\u00f3n superior. Consulta la p\u00e1gina SSO para educaci\u00f3n<\/a> para obtener m\u00e1s detalles.<\/p>\n\n\n Shibboleth es otro protocolo de SSO que suele verse en instituciones educativas, espec\u00edficamente donde un gran n\u00famero est\u00e1n federadas para compartir aplicaciones y\/o servicios. Shibboleth est\u00e1 construido con SAML como base, pero usa Discovery Service para mejorar la organizaci\u00f3n de datos de SAML de una gran cantidad de fuentes. Adem\u00e1s, Shibboleth ayuda a automatizar el an\u00e1lisis de metadatos para manejar actualizaciones de certificados de seguridad y otras configuraciones que pueden establecer instituciones individuales dentro de una federaci\u00f3n. <\/p>\n\n\n 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\u00f3n del usuario. Las credenciales existentes en la m\u00e1quina 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. <\/p>\n\n\n Los reclamos (tambi\u00e9n conocidos como \u00abafirmaciones\u00bb) son creados por un emisor de reclamos en el que conf\u00edan varias partes. Los reclamos generalmente se empaquetan en un token firmado digitalmente que se puede enviar a trav\u00e9s de la red utilizando el lenguaje de marcado de aserci\u00f3n de seguridad (SAML). <\/p>\n\n\n Es posible que un usuario demuestre que conoce su contrase\u00f1a sin proporcionar la contrase\u00f1a en s\u00ed. NTLM logra esto mediante un protocolo de desaf\u00edo y respuesta que primero determina qu\u00e9 tipo de NTLM y mecanismos de encriptaci\u00f3n admiten mutuamente el cliente y el servidor, luego codifica criptogr\u00e1ficamente la contrase\u00f1a del usuario y la env\u00eda al servidor que requiere autenticaci\u00f3n. <\/p>\n\n\n Kerberos permite a los usuarios iniciar sesi\u00f3n 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\u00f3n de claves (KDC) central. En Windows, cada controlador de dominio de Active Directory act\u00faa como un KDC. Los usuarios se autentican en los servicios (por ejemplo, servidores web) autentic\u00e1ndose primero en el KDC y luego solicitando tickets de servicio encriptados del KDC para el servicio espec\u00edfico que desean usar. Esto sucede autom\u00e1ticamente en todos los principales navegadores que usan SPNEGO (ver m\u00e1s abajo). <\/p>\n\n\n Hay instancias en las que la aplicaci\u00f3n cliente y el servidor remoto no saben qu\u00e9 tipos de autenticaci\u00f3n el otro admite. Aqu\u00ed es cuando se puede utilizar SPNEGO (Mecanismo de negociaci\u00f3n GSSAPI simple y protegido) para averiguar qu\u00e9 mecanismos de autenticaci\u00f3n est\u00e1n disponibles mutuamente. Algunos de estos mecanismos pueden incluir autenticaci\u00f3n Kerberos y NTLM. <\/p>\n\n\n El inicio de sesi\u00f3n \u00fanico reducido se usa ampliamente para limitar la cantidad de veces que se requerir\u00e1 que un usuario ingrese sus credenciales para acceder a diferentes aplicaciones. Con las aplicaciones cr\u00edticas, el SSO reducido tambi\u00e9n ofrece una t\u00e9cnica para garantizar que un usuario no inicie sesi\u00f3n sin un segundo factor de autenticaci\u00f3n proporcionado por el usuario. <\/p>\n\n\n Un usuario que inicia sesi\u00f3n en un sitio web puede optar por que sus credenciales se recuerden de forma permanente para ese sitio. Esto se logra mediante la creaci\u00f3n de una cookie cifrada en la m\u00e1quina del usuario para ese navegador web que contiene las credenciales del usuario. Esta cookie persiste en diferentes sesiones del navegador y reinicia la m\u00e1quina, pero se configurar\u00e1 para que caduque despu\u00e9s de un per\u00edodo determinado. La pr\u00f3xima 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\u00f3n despu\u00e9s de validarlas con \u00e9xito. <\/p>\n\n\n La cumplimentaci\u00f3n de formularios permite el almacenamiento seguro de informaci\u00f3n que normalmente se llena en un formulario. Para los usuarios que completan formularios repetidamente (especialmente para el acceso de seguridad), esta tecnolog\u00eda recordar\u00e1\/almacenar\u00e1 toda la informaci\u00f3n relevante y la proteger\u00e1 con una \u00fanica contrase\u00f1a. Para acceder a la informaci\u00f3n, el usuario solo tiene que recordar una contrase\u00f1a y la tecnolog\u00eda Form-filling puede encargarse de llenar en los formularios. <\/p>\n\n\n Banner XE\/Banner 9 soporta CAS SSO. Si bien no es el protocolo SSO m\u00e1s nuevo, CAS SSO mejora la usabilidad de Banner. Adem\u00e1s, CAS SSO aumenta simult\u00e1neamente los puntos de integraci\u00f3n de Banner en varias instituciones. Las instituciones de educaci\u00f3n superior que buscan opciones adicionales y m\u00e1s viables pueden optar por usar Banner XE\/Banner 9 para llenar el vac\u00edo. CAS SSO abre Banner XE\/Banner 9 a configuraciones e implementaciones m\u00e1s exclusivas.<\/p>\n\n\n\n Disfruta esta breve demo de Inicio de sesi\u00f3n \u00fanico<\/a> con las pcapacidades de PortalGuard y luego reg\u00edstrate a nuestra prueba gratuita<\/a> para probarlo.<\/p>\n\n\n\nServicio de autenticaci\u00f3n central (CAS)<\/h2>\n\n\n\n
Shibboleth SSO<\/h2>\n\n\n
SSO basado en cookies<\/h2>\n\n\n
SSO basado en notificaciones<\/h2>\n\n\n
SSO basado en NTLM<\/h2>\n\n\n
SSO basado en Kerberos<\/h2>\n\n\n
SSO basado en SPNEGO<\/h2>\n\n\n
SSO reducido<\/h2>\n\n\n
SSO basado en inscripci\u00f3n<\/h2>\n\n\n
SSO de cumplimentaci\u00f3n de formulario<\/h2>\n\n\n
Banner XE\/Banner 9<\/h2>\n\n\n
Mira el inicio de sesi\u00f3n \u00fanico de PortalGuard en acci\u00f3n<\/h2>\n\n\n\n