¿Qué es el inicio de sesión único (SSO)? ¿Cómo funciona el inicio de sesión único (SSO)?

Todos lo hacemos, y sabemos que no deberíamos. Tienes ese archivo en tu teléfono o un trozo de papel en tu billetera, o peor aún, una nota de Post-it pegada a la parte posterior de nuestro teclado, con tu nombre de usuario y contraseña. Luego está el hábito de usar el nombre de nuestro perro junto con algunos números y alguna puntuación.

La realidad es que la vida moderna en el mundo web significa que de alguna manera tenemos que rastrear docenas de nombres de cuentas y contraseñas. A menos que tengas un recuerdo notable, no todos van a ser diferentes. En su mayoría son simples, son viejos, y si alguien realmente lo intentó, son adivinables. Es un caramelo para potenciales ciberdelincuentes, y es totalmente evitable.

¿Qué es el SSO (inicio de sesión único)?

La tecnología de inicio de sesión único soluciona en parte el problema de las contraseñas que nos afecta tanto en el trabajo como en nuestra vida personal. Nos permite iniciar sesión una vez en un servidor de autenticación, que luego emite certificados en nuestro nombre que sirven como credenciales verificadas para las aplicaciones participantes.

Lo más probable es que ya hayas utilizado un sistema de este tipo. Si has elegido "Iniciar sesión con Apple", o Google, o el sistema de gestión de identidad de algún otro proveedor grande en lugar de crear una nueva contraseña para una aplicación web, estás usando un SSO. Cada vez más, el SSO se utiliza en la empresa, también, a menudo en combinación con otras tecnologías de autorización para proteger los sistemas empresariales y hacer que el mantenimiento de contraseñas sea sostenible en docenas a cientos de aplicaciones y servicios.

Conclusiones clave

• El SSO nos evita la obligación de recordar múltiples combinaciones de contraseña y nombres de usuario.
• El SSO hace que la vida sea más fácil para los equipos de TI, ya que les brinda un único sistema de autenticación para administrar para toda la organización.
• El SSO también permite a las aplicaciones autenticar usuarios en los servicios que la aplicación necesita para funcionar, como los que gestionan conexiones de red o comprueban actualizaciones de software.

SSO en detalle

El concepto de inicio de sesión único es sencillo: en lugar de proporcionar un nombre de usuario y una contraseña o identificarse de otra manera con cada aplicación que utilices, proporciona esa información una sola vez a un servidor de autenticación. Una vez hecho esto, el servidor de autenticación envía certificados de identificación en tu nombre cuando accedes a cualquier aplicación que participa en el sistema de SSO.

El SSO reduce el número de nombres de usuario y contraseñas que necesita conocer. También puede reducir en gran medida el número de veces que se te pide que proporciones credenciales de identificación, lo que facilita el uso de una amplia gama de aplicaciones y es más probable que crees contraseñas más seguras. Desde el punto de vista de los planificadores de TI empresariales, el SSO les permite actualizar los procedimientos de seguridad y desplegar mecanismos de autenticación más avanzados para ser utilizados por el servidor de autenticación, lo que permite a todas las aplicaciones participantes disfrutar de una autenticación más segura sin necesidad de modificación.

En tu vida personal, el uso del sistema de autenticación de un proveedor importante en lugar de configurar manualmente un nuevo nombre de usuario y contraseña en cada aplicación aporta diferentes beneficios. Una ventaja principal es que los grandes proveedores que ofrecen servicios federados de gestión de identidad son buenos para proteger las contraseñas y otros datos personales que les confían los clientes. Es posible que un nuevo proveedor con una nueva aplicación no proteja tan bien las credenciales que proporciona.

¿Cómo funciona el inicio de sesión único (SSO)?

El SSO funciona solicitando a los usuarios que se autentiquen en un servidor SSO en lugar de en aplicaciones individuales. Una vez completado el proceso de autenticación, el servidor SSO proporciona certificados a las aplicaciones a las que un individuo autenticado desea acceder. Los certificados sirven para verificar la identidad del usuario.

Por lo general, los certificados solo son válidos durante un cierto periodo de tiempo y, por lo general, están vinculados al sistema desde el que se autentican los usuarios individuales. Para participar, las aplicaciones se deben escribir de forma que puedan utilizar el servicio SSO. En la empresa, los planificadores de TI normalmente elegirán un modelo SSO y, a continuación, necesitarán que las aplicaciones lo utilicen para verificar las identidades de los empleados. Esto puede ser un problema para las aplicaciones monolíticas más antiguas que crean sus propios repositorios de credenciales de usuario o que pueden no soportar arquitecturas SSO comunes.

Tipos de configuración de SSO comunes

Los componentes y conceptos comunes de SSO comparten varias características, incluida la gestión de identidad centralizada, la estandarización y las sólidas medidas de seguridad. Una clave es la interoperabilidad: estos sistemas deben trabajar juntos para asegurarse de que el proceso de autenticación sea fácil de usar y funcione sin problemas en múltiples aplicaciones. Cuando eso se logra, los equipos de TI encontrarán que son capaces de exigir contraseñas más seguras y autenticación de dos factores con un rechazo mínimo.

• SAML. El lenguaje de marcado para confirmaciones de seguridad (SAML) es una especificación técnica que describe la estructura de un documento que servirá para autenticar usuarios en aplicaciones. SAML utiliza el estándar XML ampliamente aceptado para especificar la estructura del documento que los servidores de identidad, también conocidos como proveedores de identidad, crean y envían a las aplicaciones. Estas aplicaciones se denominan a menudo "proveedores de servicios" en el lenguaje SSO. Cualquier proveedor de identidad que utilice SAML creará credenciales de autenticación que puede utilizar cualquier aplicación que conozca SAML, convirtiéndola en una buena opción para las aplicaciones de Internet.

  El SAML no proporciona un mecanismo para garantizar que la información de autenticación que recibe una aplicación no se modifica. Eso es manejado por otra tecnología.

• Kerberos. Creado en el MIT a finales de la década de 1980 como parte del Proyecto Athena, Kerberos es una arquitectura de autenticación y autorización completa. El Proyecto Athena buscó crear una red de recursos informáticos universalmente accesibles para los estudiantes del MIT en todo el campus. Kerberos utilizó originalmente el estándar de cifrado de datos (DES) para cifrar mensajes que se transfirieron entre los servidores de autenticación y las aplicaciones. Utilizó claves simétricas de 48 bits, lo que significa que la misma clave se utiliza para cifrar y descifrar mensajes. En ese momento, DES era la forma más segura de cifrado disponible como estándar mantenido por el Instituto Nacional de Estándares y Tecnología (NIST).

  Actualmente, Kerberos utiliza el estándar de cifrado avanzado (AES), que sustituyó a DES en los estándares de cifrado del NIST. AES especifica claves más largas, de hasta 256 bits de longitud, y permite múltiples rondas de cifrado, lo que hace que el sistema sea muy difícil de descifrar.

  Debido a que Kerberos utiliza cifrado de claves simétricas, requiere que un tercero de confianza gestione las claves, lo que lo hace más apropiado para aplicaciones empresariales donde un dominio de uso se puede establecer firmemente, generalmente limitado a las LAN y VPN de la empresa. Aunque Kerberos se puede utilizar en Internet, donde no se establecerá ningún dominio mediante un estándar de autenticación diferente (cifrado de clave pública) para iniciar el proceso, rara vez se utiliza de esta manera. Kerberos puede utilizar su propio formato de credencial o configurarse para utilizar SAML. Sigue siendo popular, incluso con Microsoft, que usa por defecto Kerberos en lugar de su sistema de autenticación NTLM menos seguro para redes empresariales.

• OAuth. Como marco de autorización abierto que no incluye un marco de autenticación, OAuth es el sistema por defecto cuando una aplicación de Internet necesita acceder a los recursos de un servicio protegido en nombre de un usuario. La mayoría de los proveedores de nube, incluido Oracle con su Oracle Cloud Infrastructure (OCI), utilizan OAuth para gestionar el acceso a sus recursos en la nube. Oracle también ofrece bibliotecas y servicios que facilitan a los desarrolladores la creación de sus propias aplicaciones que utilizan OAuth.

  Los siguientes son los componentes principales de un sistema OAuth:

  • El sistema cliente, generalmente una aplicación de usuario final que puede que desee acceder a los recursos de varios servicios disponibles en Internet.
  • Servidor de autorización, que recibe solicitudes de tokens que permitirán a un cliente acceder a servicios protegidos. El servidor de autorización recibirá solicitudes de tokens junto con el certificado de autenticación del cliente. Emitirá tokens de acceso que han sido autorizados por el propietario del recurso.
  • El servidor de recursos, que tiene la información o proporciona el servicio que el cliente está buscando utilizar. Proporciona datos o servicios cuando recibe tokens de acceso válidos del cliente.

  El token de acceso puede especificar una variedad de tipos de permiso de acceso. Los distintos tipos se emiten según el nivel de confianza requerido y la naturaleza del dispositivo cliente. Por ejemplo, un televisor inteligente puede recibir un permiso de acceso diferente al de un portátil.

• OpenID Connect (OIDC). OpenID Connect es el sistema de gestión de identidades creado para utilizarse con OAuth. Juntos, OIDC y OAuth proporcionan un entorno SSO completo para aplicaciones basadas en web y sistemas nativos de Internet, como aplicaciones móviles. En lugar de utilizar SAML como base para devolver información de credenciales, OIDC utiliza un documento JSON conocido como tokens web JSON, que se describe a continuación, y protocolos RESTful; ambos son nativos de Internet y fáciles de usar para los desarrolladores.

  En lugar de utilizar el cifrado de claves simétricas como lo hace Kerberos, OIDC utiliza el cifrado de claves públicas, que se presta mejor a redes sin dominio como Internet.

• Autenticación de tarjeta inteligente. Sistemas como OIDC utilizan cifrado de clave pública para garantizar que solo los destinatarios deseados puedan ver los datos intercambiados con un proveedor de gestión de identidad durante y después de la autenticación. El cifrado de claves públicas es asimétrico e implica una clave pública, que se puede utilizar para cifrar los mensajes que se van a enviar a un cliente o servidor, y una clave privada que es secreta y que se debe utilizar para descifrar mensajes.

  Normalmente, las claves privadas se almacenan en el dispositivo de un usuario. La mayoría de las computadoras portátiles vienen con un chip a prueba de alteraciones que utiliza la tecnología Trusted Platform Module (TPM) para descifrar los mensajes destinados al sistema. Los teléfonos Apple y Android utilizan sistemas diferentes, pero similares. El de Apple se llama Secure Enclave y el de Android se llama Android Knox. Estas tecnologías permiten que el dispositivo proporcione su clave pública a cualquier sistema que lo solicite correctamente y utilizará su clave privada que nunca se divulga para descifrar los mensajes que recibe.

  La ventaja de estos sistemas es que el usuario del dispositivo no necesita saber nada sobre cómo se maneja el cifrado en sus sistemas. La desventaja es que cada dispositivo que posee el usuario tendrá un par de claves públicas/privadas único, por lo que los dispositivos se conocen individualmente en el proceso de cifrado. Si un ordenador portátil o teléfono se pierde o es robado, su sistema de cifrado no ayudará a evitar el acceso si el ladrón conoce la contraseña del propietario.

  El uso de una tarjeta inteligente con un chip similar a los chips incrustados en las tarjetas de crédito permite a los usuarios autenticarse con un conjunto de claves, independientemente de los dispositivos que estén utilizando. El chip de la tarjeta es su propio microprocesador, por lo que debe insertarse en un lector de tarjetas o activarse y alimentarse mediante una tecnología RFID, como las comunicaciones de campo cercano. La seguridad de las tarjetas inteligentes es similar a la que ofrecen los chips TPM.

• SSO de empresa. Las grandes organizaciones con infraestructuras de aplicaciones complejas pueden crear un sistema SSO de empresa, o eSSO, que se limita a los límites de sus redes. Los empleados apreciarán la necesidad de conocer solo una o dos contraseñas y nombres de usuario para acceder a las aplicaciones que su trabajo requiere, y la organización se beneficiará de una seguridad más eficaz y manejable para los sistemas y los datos. Estos sistemas eSSO pueden preferir el cifrado de claves simétricas en función de su capacidad para revocar claves más fácilmente y SAML por su formato conocido, y a menudo emplean varios tipos de autenticación multifactor para una mejor seguridad de punto final.

  A medida que las aplicaciones SaaS se vuelven más comunes, las empresas tienen la opción de avanzar hacia un sistema como OAuth que se utiliza con más frecuencia en Internet o que requiere que las aplicaciones SaaS se ajusten al marco de eSSO que haya elegido la compañía. SAML se puede utilizar en la red empresarial y en Internet. Muchas aplicaciones SaaS soportarán ambos marcos para la autenticación de usuarios.

• SSO web. Es probable que las aplicaciones web funcionen mejor o se limiten a utilizar OAuth para autorizar la actividad del usuario y OpenID Connect para autenticar usuarios. Como se supone que Internet es el transporte, los componentes de un sistema Web SSO se definen como un estándar IETF y, por lo tanto, tienden a funcionar de una manera que los desarrolladores web esperan y aprecian. Además, la autenticación está estrechamente vinculada con la autorización y utiliza métodos de acceso como protocolos REST y estándares de información basados en JSON para crear un sistema completo y ampliable. Los sistemas de SSO web también están diseñados para funcionar en todos los dominios y a escala.

• LDAP. El protocolo ligero de acceso a directorios se introdujo por primera vez en la década de 1990 para permitir a los usuarios encontrar recursos que pudieran utilizar en una red local, como servidores o impresoras. Prevé un servidor autorizado que conocerá todos los recursos dentro de un dominio. Como tal, no es adecuado para su uso en Internet.

  Dado que el LDAP se utiliza para otorgar acceso a los recursos de red, incluye un sistema de autenticación de usuarios con las credenciales del usuario almacenadas en el servidor LDAP. Sus mecanismos de autenticación de usuarios no son sólidos; por ejemplo, envía contraseñas a través de la red como texto no cifrado. Otro protocolo puede proporcionar cifrado, como SSL/TLS.

  El protocolo LDAP tiene la ventaja de ser flexible y ampliable, por lo que las empresas pueden utilizarlo para almacenar información adicional sobre los empleados, como roles organizativos y afiliaciones a grupos, y atributos como la ubicación de la oficina y el número de teléfono. Sin embargo, a menudo se requieren privilegios de acceso más detallados en la empresa (imagina la información sobre quién tiene acceso a ciertos datos) y esos derechos de acceso no pueden ser gestionados fácilmente mediante un protocolo LDAP.

• JWT. JSON Web Tokens son documentos compactos que se utilizan para transmitir información de forma segura entre las diversas partes de una manera estructurada. Cumplen la misma necesidad que los documentos SAML, pero en formato más breve, lo cual los convierte en una opción adecuada para su inclusión en las URL. Los JWT se firman criptográficamente mediante técnicas de cifrado de clave pública para garantizar la autenticidad. En Open Authentication (Oath), una vez que se autentica un usuario, el servidor de identidad devolverá un token de ID de JSON.

  Las solicitudes de autorización para acceder a recursos protegidos devolverán posteriormente un token de acceso JSON, que se debe incluir con cada solicitud en el servidor de recursos. Tales transacciones transfieren el estado del cliente, en este caso, autenticado y autorizado, como parte de cada solicitud, lo que los convierte en los llamados intercambios RESTful. REST, que significa "transferencia de estado representacional", es beneficioso porque los servidores de recursos no necesitan establecer y mantener sesiones con cada cliente que desee utilizar los recursos del servidor.

  Los JWT son documentos de texto no cifrado, por lo que se deben utilizar en conexiones cifradas con HTTPS. Los tokens generalmente están diseñados para que no contengan datos confidenciales, como información de identificación personal. Debido a que cada token se firma de acuerdo con X.509, el estándar internacional para formatear certificados de clave pública, esa firma será validada por los servidores de recursos para garantizar que el token no se haya alterado. Los JWT son componentes de un sistema de autenticación y autorización OAuth/OpenID. Están diseñados para su uso en aplicaciones web, presentan una adecuada escalabilidad y están destinados a ser utilizados en todos los dominios.

Ventajas del SSO

Los profesionales de TI y seguridad tienden a ser fanáticos del SSO; entienden que significa centralizar la autenticación de usuarios, proteger información potencialmente confidencial y gestionar la integración con sistemas y aplicaciones empresariales. Por lo general, están encantados de abordar la formación de usuarios necesaria y abordar la supervisión y el mantenimiento continuos. Eso es un resultado directo de varios beneficios significativos que vienen con la tecnología.

• Acceso centralizado. Los sistemas SSO simplifican la carga de gestionar las cuentas de usuario y el acceso a las múltiples aplicaciones que mantiene la mayoría de las empresas y los proveedores de Internet en la nube. El acceso del usuario a todas las aplicaciones se puede otorgar y revocar en un solo lugar. Por ejemplo, si un empleado abandona una organización, los administradores no tendrán que eliminar las credenciales del empleado para cada aplicación individualmente. Los profesionales de la seguridad también pueden realizar cambios en los sistemas de autenticación en un solo lugar, y no tener que realizar cambios en cada aplicación.
• Mayor seguridad. El SSO reduce en gran medida el número de pares de nombre de usuario y contraseña que los empleados deben confiar a la memoria. Con esa carga reducida, es razonable, particularmente para las empresas, mejorar la seguridad de los intercambios de autenticación con autenticación multifactor y políticas de contraseñas seguras.
• Mayor productividad de los empleados. Los empleados tendrán menos dificultades para recordar los nombres de usuario y las contraseñas cuando SSO esté en su lugar. Una vez autenticadas, las personas suelen acceder a las aplicaciones sin volver a autenticarse. Por lo tanto, el SSO debería permitir que los empleados lleguen a su trabajo previsto de manera más rápida. En función de los detalles de implantación, es posible que aún se les solicite que se autentiquen en las aplicaciones que utilizan, pero al menos solo tendrán que recordar sus credenciales de SSO.
• Reducción de la fatiga de las contraseñas. Seamos realistas, nadie quiere lidiar con docenas de pares de nombre de usuario y contraseña. La dificultad de recordar contraseñas complejas, especialmente si es necesario cambiarlas con frecuencia, puede generar frustración y provocar que las personas usen contraseñas fáciles de adivinar, reutilicen la misma contraseña para varias cuentas o utilicen el método de gestión de contraseñas anotándolas en papel. El SSO aligera la carga.
• Cumplimiento normativo. El SSO puede facilitar el cumplimiento normativo a través de las ventajas de la gestión de acceso centralizada que se acaba de describir. La auditoría y la solución también se simplifican, ya que solo hay un marco de SSO que comprobar.
• Integración simplificada. Una empresa típica gestiona petabytes de datos almacenados en muchas instancias de base de datos. No es difícil imaginar una base de datos para datos de fabricación, otra para datos de la cadena de suministro y otras para datos financieros, de marketing, de ventas, etc. También es fácil entender lo útil que sería para los vendedores tener acceso a los datos de inventario, por ejemplo. Un sistema CRM podría acceder a esos datos, pero se deben conocer todos los vendedores en la base de datos de gestión de inventario y en su sistema CRM. El SSO puede proporcionar la identidad verificada necesaria del solicitante, y los tokens de acceso pueden ayudar a determinar qué datos debe permitir ver una persona en cada rol. Sin SSO, la integración entre el CRM y el sistema de inventario sería mucho más difícil de crear y gestionar e implicaría otro paso de autenticación para los usuarios o una seguridad potencialmente más débil para los datos de inventario.
• Experiencia de usuario simplificada. Reducir la necesidad de autenticarse en aplicaciones empresariales y aplicaciones web generalmente hace que la experiencia del usuario sea mejor. Y debido a que muchas personas están acostumbradas a SSO a través de su presencia personal en línea, a menudo se requiere una capacitación mínima.

SSO y seguridad: ¿El SSO es seguro?

En primer lugar, no hay tal cosa como seguro, solo hay grados de seguridad. Dicho esto, cualquier marco de SSO disponible comercialmente será altamente seguro, eso es parte del objetivo de la tecnología. Generalmente, el sistema SSO por sí solo no es una solución de seguridad total. Más bien es un componente importante de un entorno seguro. Su papel como sistema tanto para autenticar usuarios como para proporcionar credenciales de autenticación a aplicaciones y otros sistemas que proporcionan recursos es una parte fundamental de una estrategia de seguridad general.

SSO y privacidad

SSO se presta a una mejor privacidad, pero la privacidad puede variar con cada implementación. Por ejemplo, las respuestas de SAML y JWT contendrán, como mínimo, una afirmación de autenticación. También pueden contener información, como grupos y roles que se aplican al usuario, así como otros datos que los implantadores deciden proporcionar.

En redes sociales o empresas retail online, puede ser útil para la aplicación conocer la edad, la ubicación y otra información personal del usuario. En general, si está demostrando dicha información personal a Facebook, asuma que Facebook se la proporcionará a otros a menos que la política de privacidad diga que no lo hará o que la aplicación le permita decir explícitamente que no comparta alguna información.

En la empresa, los sistemas SSO deben devolver afirmaciones de autenticación junto con los roles pertinentes que el usuario desempeña en la organización. También puede ser útil ofrecer la oficina en la que trabaja el usuario y el número de teléfono de la empresa. Otra información debería ser más difícil de obtener. Lo que se proporciona por defecto suele estar dictado por las políticas de RR. HH.

Casos de uso de SSO

El SSO está diseñado para proporcionar a los usuarios un acceso perfecto a varias aplicaciones y sistemas con solo un juego de credenciales de inicio de sesión. Si bien las organizaciones que tienen estrictos requisitos de cumplimiento normativo pueden encontrar que necesitan implementar medidas de seguridad adicionales, el SSO ofrece multitud de casos de uso. A continuación, detallamos algunos:

• Aplicaciones empresariales. Una empresa suele gestionar de docenas a cientos de aplicaciones, cada una de las cuales requiere que los usuarios se autentiquen. Crear y mantener sistemas de gestión de identidad por aplicación no resulta práctico para los usuarios o los equipos de TI. El SSO ofrece una forma de autenticar a los empleados una vez y, a continuación, gestionar su autorización para utilizar recursos en función de esa autenticación puntual.

  Las afirmaciones de autenticación suelen ser válidas solo durante un periodo determinado y en un único sistema. El sistema de SSO puede conservar detalles más detallados sobre los roles de cada empleado dentro de la compañía y los pueden utilizar las aplicaciones o los sistemas de autorización para proporcionar acceso limitado a aplicaciones, datos y otros recursos.

• Aplicaciones en la nube. Tanto para uso empresarial como de consumo, los sistemas basados en la nube incluyen diferentes necesidades de identificación y autorización frente a los sistemas SSO destinados a la empresa. Para los consumidores, por comodidad, los usuarios que se autentiquen una vez puedan utilizar el servicio perpetuamente desde ese dispositivo. Una vez conectado a Gmail, por ejemplo, puedes usarlo, junto con otras aplicaciones de Google, como Docs o Sheets, sin necesidad de volver a autenticarse. En los negocios, los proveedores de servicios en la nube que ofrecen aplicaciones o plataformas SaaS e infraestructura como servicio también permitirán un amplio acceso a sus servicios una vez que se confirme la identidad del usuario. La autenticación es el primer paso en un esquema de autorización de servicio más grande que permite a los usuarios iniciar sesión una vez y utilizar una amplia gama de servicios. El acceso al servicio dependerá del rol de cada usuario para cada aplicación, tal vez sea administrador de una aplicación, desarrollador de una segunda y usuario final de una tercera. El acceso también dependerá de lo que la organización haya pagado.

Implementación de SSO

No dejes que la falta de experiencia interna en seguridad te disuada a la hora de adoptar un SSO. Los proveedores de servicios de seguridad gestionados, así como los equipos de implementación de proveedores de SSO, están ahí para ayudarte. Muchas empresas optan por utilizar los servicios SSO ofrecidos por proveedores externos. La empresa se beneficia de la experiencia, las funciones de seguridad avanzadas y la escalabilidad, y los equipos de TI pueden centrarse en ayudar a hacer crecer el negocio mientras dejan la gestión de SSO en manos de expertos.

En un nivel elevado, la aplicación requiere tres elementos principales.

1. Selección y distribución de sistemas de autenticación de clientes que recopilarán de forma segura las entradas del usuario final, como el nombre de usuario y la contraseña. Incluso en la empresa, estos sistemas a menudo se entregan como páginas web, por lo que es fácil mantener los procesos de autenticación uniformes en todos los dispositivos. En general, en la empresa, el usuario debe estar en la red de la compañía o acceder a ella a través de una VPN. Este requisito permite a la organización crear un único sistema de gestión de ID autorizado.
2. Configuración de un gestor de ID que autenticará a los usuarios y emitirá certificados en nombre de la organización. En la mayoría de las tiendas, el administrador de ID será parte de un sistema que también proporciona tokens de autorización de usuario que permiten a las aplicaciones saber lo que una persona puede hacer dentro de la aplicación o están estrechamente vinculados al servidor de autorización.
3. Configurar o modificar aplicaciones para utilizar los certificados y tokens de los sistemas de SSO y autorización en lugar de mantener su propio sistema de ID de usuario.

Mejores prácticas de SSO

Ya sea que esté implementando internamente, con la ayuda de un tercero o utilizando un modelo como servicio, hay claves para el éxito. A continuación, detallamos algunos:

1. Mandato de autenticación multifactor (MFA). Así como SSO permite a las organizaciones aplicar políticas de contraseñas desde un único marco, también que las organizaciones implementen una tecnología de identificación más sólida, conocida colectivamente como autenticación multifactor. Estos factores pueden incluir tarjetas inteligentes, aplicaciones que se ejecutan en teléfonos inteligentes, varias formas de autenticación biométrica y otros.
2. Uso del control de acceso basado en roles (RBAC). La autenticación de usuarios soluciona solo una parte del problema de la gestión del acceso a los recursos empresariales. El otro desafío es limitar el acceso de los usuarios solo a los recursos que pueden utilizar. Al establecer grupos, como marketing, finanzas, fabricación y ventas, y al establecer roles dentro de cada grupo para sus miembros, el control de acceso se puede ajustar y mantener en una ubicación central y manejable.
3. Auditoría y actualización de estándares. Centrar la autenticación en un único marco de mecanismos simplifica enormemente la auditoría y el proceso de realizar actualizaciones para cumplir con los nuevos estándares a medida que surgen.
4. Implantación de la gestión de roles y permisos. SSO se presta a una filosofía de confianza cero. Los usuarios solo pueden acceder a los recursos explícitamente necesarios para sus roles y solo pueden ver los datos para los que tienen permiso explícito.
5. Cumple los requisitos de privacidad de los datos. El uso de un marco de SSO no garantiza el cumplimiento de las leyes de privacidad de datos, pero puede hacer que dicho cumplimiento sea mucho más fácil de lograr y demostrar.

Control del acceso de forma segura y sencilla con Oracle

¿Necesitas gestionar las identidades de los usuarios y el acceso a Oracle Cloud Infrastructure (OCI) y a través de aplicaciones en la nube y locales? Para las organizaciones que buscan una estrategia de seguridad de confianza cero, Oracle Cloud Infrastructure Identity and Access Management (IAM) proporciona las herramientas de gestión e integración que necesitas.

¿Estás interesado en implementar un autenticador universal con soporte de autenticación multifactor? Oracle Access Management ofrece un sistema flexible que se puede ejecutar en entornos locales o en la nube. Las organizaciones pueden permitir que estas políticas sigan al usuario independientemente del dispositivo y la ubicación para proteger el acceso a los datos en cualquier lugar, en cualquier momento y desde cualquier dispositivo. Junto con la MFA, la cartera de IAM de Oracle admite SSO de dispositivos de confianza y SSO de aplicaciones, todo lo necesario para lograr principios y mandatos de arquitectura de confianza cero.

A medida que las empresas confían en más aplicaciones y las aplicaciones dependen de más servicios y fuentes de datos para hacer su trabajo, la autenticación y autorización de usuarios se vuelven más difíciles de gestionar. Los marcos SSO simplifican la vida tanto para los usuarios finales como para los arquitectos de aplicaciones al simplificar el proceso de autenticación y autorización.

Preguntas frecuentes sobre SSO

¿Qué significa SSO?

SSO son las siglas de Single Sign-On (inicio de sesión único).

¿Cuál es mi cuenta de SSO?

Tu cuenta SSO es un servicio de autenticación centralizado que te permite utilizar un juego de credenciales de conexión para acceder a varias aplicaciones y sistemas. Esto significa que solo tienes que recordar un nombre de usuario y una contraseña para acceder a todos los servicios y recursos que proporciona tu organización. Las cuentas SSO optimizan el proceso de inicio de sesión, mejoran la seguridad y facilitan a los usuarios el acceso a la información y las herramientas que necesitan para realizar su trabajo.

¿Cuál sería un ejemplo de SSO?

En el espacio de consumo, grandes proveedores como Amazon, Google, Meta y Microsoft pueden actuar como una fuente de credenciales de usuario para otras aplicaciones. Si te ha aparecido un cuadro de diálogo que te permite introducir tus credenciales o conectarte mediante uno de los servicios anteriores, estás utilizando un SSO.