Aprender el lenguaje de los protocolos de identidad

Objetivos de aprendizaje

Después de completar este módulo, podrá:

Identificar los estándares de la industria empleados para la gestión de la identidad y el acceso.
Conocer cómo SAML está relacionado con XML.
Conocer la diferencia entre un proveedor de identidad y un proveedor de servicios.

Estándares y protocolos de identidad

¿Le resulta difícil de creer que puede mantener las identidades de sus usuarios seguras cuando no tienen que iniciar sesión en sitios web o aplicaciones externos? ¿Cómo pueden funcionar los productos de tantas compañías diferentes los unos con los otros, incluso los productos que compiten entre sí?

La respuesta es: los estándares y protocolos de la industria para la gestión de la identidad y el acceso. Esto puede sonar intimidatorio, pero no tiene que ser así. Un estándar es simplemente un conjunto de prácticas ampliamente aceptadas que siguen los miembros de la industria. Un estándar puede incluir un protocolo que especifica el modo en que los sistemas intercambian información.

A continuación aparecen tres protocolos que Salesforce y otros proveedores de identidad siguen para implementar soluciones de identidad.

SAML
OAuth 2.0
OpenID Connect

Protocolo SAML

Cuando desea que los usuarios se muevan fácilmente entre organizaciones y aplicaciones de Salesforce sin tener que iniciar sesión repetidamente, debe configurar el inicio de sesión único (SSO). Security Assertion Markup Language (SAML, lenguaje de marca de afirmación de seguridad, por sus siglas en inglés) es el protocolo que lo posibilita.

A continuación se describen un par de ejemplos de SAML en acción.

Cuando inicia sesión en Salesforce y luego hace clic en el Iniciador de aplicación para pasar directamente a su bandeja de entrada de Gmail, eso es SAML en acción.
Cuando los usuarios que ya iniciaron sesión en otra aplicación pueden acceder a su organización de Salesforce sin iniciar sesión de nuevo, eso es también SAML en acción.

Afirmación SAML

Así es como funciona SAML. Un usuario intenta acceder a un servicio. El proveedor de servicios envía una solicitud al proveedor de identidad preguntando básicamente “Oye, ¿vale que este usuario acceda a mi servicio?”. El proveedor de identidad se asegura de que los usuarios son quienes dicen ser comprobando su base de datos y luego devolviendo una respuesta (una afirmación) que dice: “Sí, este usuario está autorizado, aquí entrego algo de información sobre el usuario”.

Espere un minuto. ¿Cuál es la diferencia entre un proveedor de identidad y un proveedor de servicios? Básicamente, el proveedor de identidad es el que autentica el usuario. El proveedor de servicios está solicitando la identidad autenticada. Hablaremos más sobre los proveedores de identidad y servicios más adelante en esta unidad.

La afirmación es la información que se envía. Una afirmación puede transportar información detallada sobre un usuario. También puede contener atributos acerca del usuario, como nombres y apellidos, información de contacto, quizás incluso un puesto de trabajo.

SAML funciona en segundo plano. Sus usuarios no lo ven en absoluto. Solo hacen clic en un icono o vínculo y abren otra aplicación sin tener que proporcionar información adicional o iniciar sesión de nuevo. A veces su destino ya sabe algo sobre ellos (esos atributos de usuario) cuando llegan allí.

SAML y XML

SAML es un protocolo basado en XML, lo que significa que los paquetes de información que se intercambian están redactados en XML. XML se supone que es (casi) legible por los humanos, de modo que puede obtener una idea de lo que está ocurriendo. Eso es bueno cuando está intentando determinar si las cosas están funcionando correctamente.

El siguiente diagrama ilustra una parte de una afirmación SAML. ¿Le parece un sinsentido? Mire de nuevo y verá que no lo es tanto. Contiene información sobre el nombre de usuario, su número de teléfono y su nombre de pila.

En este ejemplo, la organización de Salesforce pasa la información del usuario a otra aplicación. La aplicación puede utilizar esa información para autorizar al usuario y personalizar la experiencia del usuario. Pero lo que es más importante, el usuario no tiene que iniciar sesión de nuevo para acceder a la aplicación.

Protocolo OAuth 2.0

OAuth (Open Authorization) 2.0 es un protocolo abierto que se utiliza para permitir el uso compartido de datos seguro entre aplicaciones. El usuario trabaja en una aplicación pero ve datos de otra. Por ejemplo, inició sesión en su aplicación móvil Salesforce y ve sus datos desde su organización de Salesforce.

Entre bastidores, las aplicaciones realizan un tipo de negociación y luego solicitan al usuario que autorice esta colaboración de datos. Cuando los desarrolladores desean integrar su aplicación con Salesforce, utilizan las API de OAuth.

A continuación se describen un par de ejemplos.

Una aplicación móvil que extrae contactos de una organización de Salesforce utiliza OAuth.
Una organización de Salesforce que obtiene contactos de otro servicio también utiliza OAuth.

A continuación aparece un ejemplo de una aplicación que solicita permiso al usuario para acceder a información empleando OAuth 2.0.

Registro de Oauth de ejemplo

Protocolo OpenID Connect

El protocolo OpenID Connect agrega una capa de autenticación sobre OAuth 2.0 para activar intercambio seguro de información del usuario. Del mismo modo que SAML, OpenID Connect envía información de identidad desde un servicio a otro. A diferencia de SAML, OpenID Connect está construido para el mundo de las redes sociales de la actualidad. ¿Instaló alguna vez una nueva aplicación y se encontró con una solicitud como "Iniciar sesión con su cuenta de Google"? Esta aplicación está utilizando el protocolo OpenID Connect. Cuando inicia sesión con Google, no está creando una cuenta y otra contraseña. Solo Google alberga esa información.

Inicio de sesión con redes sociales con OpenID Connect

El desarrollador de la aplicación utilizó el protocolo OpenID Connect para activar el inicio de sesión de redes sociales.

Por ejemplo, cuando Google verifica la identidad de un usuario en nombre de otro servicio, está autenticando al usuario. De esta manera, Google es un proveedor de identidad.

Salesforce acepta varios de los proveedores de identidad sociales más importantes, incluyendo Google, Facebook, y LinkedIn. Si un proveedor no se admite directamente, es posible utilizarlo si este implementa el protocolo OpenID Connect, como lo hacen Amazon y PayPal, por ejemplo.

La ventaja del protocolo OpenID Connect para los usuarios es que pueden reducir el número total de cuentas, nombres de usuario y contraseñas que deben recordar. Por otro lado, los desarrolladores pueden autenticar a sus usuarios en distintos sitios web y aplicaciones sin tener que tener la propiedad y la gestión de archivos de contraseñas. Este proceso hace que sea mucho más difícil para los hackers poner en peligro las cuentas de usuario.

Proveedores de servicios y proveedores de identidad

En el proceso de autenticación de usuarios, SAML intercambia información de identidad entre el titular de la información, denominado proveedor de identidad (IdP), y el servicio que se desea, denominado proveedor de servicios.

En el caso donde un usuario inicia sesión en Salesforce y luego accede a Gmail, Salesforce es el proveedor de identidad y Google el proveedor de servicios. Salesforce puede ser proveedor de servicios y proveedor de identidad.

Salesforce como proveedor de servicios

Los usuarios autenticados pueden pasar desde un proveedor de identidad externo a Salesforce. En este caso, Salesforce es un proveedor de servicios: los usuarios desean obtener acceso a este servicio, y su proveedor de identidad se lo permite. Esta configuración de Salesforce es habitual porque a menudo su compañía ya está utilizando un proveedor de identidad. El proveedor de identidad podría ser uno de los que se encuentran en el mercado, como Active Directory Federation Services (ADFS) de Microsoft, PingFederate de Ping Identity, Shibboleth de código abierto, o OpenAM de ForgeRock.

Los usuarios inician sesión desde un proveedor de identidad y luego se redireccionan a Salesforce (el proveedor de servicios). En otro módulo configurará SSO con Salesforce como proveedor de servicios y una aplicación externa como el proveedor de identidad externo.

Salesforce como proveedor de identidad

Los usuarios autenticados también pueden pasar desde Salesforce a otras nubes y aplicaciones. En este caso, Salesforce actúa como proveedor de identidad y proporciona SSO para que los usuarios se conecten con diferentes proveedores de servicios.

Flujo SAML para SSO

Para los curiosos, el siguiente diagrama muestra cómo la comunicación SAML fluye durante el proceso de SSO. Esto es lo que está ocurriendo entre bastidores. No se preocupe si no está interesado en mirar. No entra en la prueba.

El proceso de SSO se desarrolla a la velocidad del rayo, pero lleva aparejado unos pasos.

Un usuario intenta acceder a Salesforce.
Salesforce reconoce la solicitud de SSO y genera una solicitud SAML.
Salesforce redirige la solicitud SAML al navegador.
El navegador redirige la solicitud SAML al proveedor de identidad externo.
El proveedor de identidad verifica la identidad del usuario y empaqueta la afirmación SAML que contiene la autenticación de usuario.
El proveedor de identidad envía la afirmación SAML al navegador.
El navegador redirige la afirmación a Salesforce.
Salesforce verifica la afirmación.
El usuario ahora inició sesión y puede acceder a Salesforce.

Hoja de referencia de terminología sobre la identidad

¿Qué le parece un curso intensivo sobre el tema de los protocolos de identidad? Cuando las palabras suenan familiares y las diferencias están matizadas, puede ser difícil tener las cosas claras. Así que aquí tiene una hoja de referencia. ¡Esperamos que le ayude!

Un término	que se confunde fácilmente con este término
Autenticación significa quién es una persona. En la actualidad, autenticación se utiliza a menudo como abreviatura de autorización y autentificación.	Autorización significa lo que una persona puede hacer.
Protocolo especifica el conjunto de reglas que permiten a los sistemas intercambiar información. Normalmente, el término protocolo y estándar se utilizan indistintamente.	Estándar es una especificación, un conjunto de prácticas de la industria que los proveedores acuerdan apoyar. A menudo, un estándar contiene un protocolo para especificar el modo en que las compañías implementan el estándar.
Nombre de usuario y contraseña son lo que el usuario proporciona para iniciar sesión en un sistema.	Credenciales son básicamente la misma cosa.
Inicio de sesión único (SSO) permite a una persona iniciar sesión una vez y acceder a otras aplicaciones y servicios sin tener que iniciar sesión de nuevo.	Inicio de sesión en redes sociales permite a una persona iniciar sesión en una aplicación empleando las credenciales establecidas con una cuenta en redes sociales como Google. La aplicación acepta las credenciales de Google y el usuario no tiene que crear otra cuenta y contraseña.
Proveedor de identidad es un servicio de confianza que permite a los usuarios acceder a otros sitios web y servicios sin iniciar sesión de nuevo.	Proveedor de servicios es un sitio web o servicio que aloja aplicaciones y acepta la identidad de un proveedor de identidad.

¿Qué es lo siguiente?

Tuvo una presentación en torbellino de estándares de la industria para la gestión de la identidad y el acceso. No se preocupe si no tiene claras las ideas. Por ahora, solo recuerde que Salesforce Identity utiliza protocolos para implementar sus funciones.

¡Ahora empieza lo divertido! ¿Tuvo suficiente de conceptos y definiciones? Pongamos algo de lo que aprendió en acción. Más adelante en esta ruta, configurará funciones de seguridad en su organización de Salesforce Dev.