Cómo implementar SSO (inicio de sesión único)

En los dominios con SSO habilitado sin máscaras de red, Google requiere ahora que los superadministradores inicien sesión con su nombre de usuario y contraseña de Google, y redirige a los usuarios que no son superadministradores a la página de inicio de sesión único.

Google Apps ofrece un servicio de inicio de sesión único a clientes que usan Google Apps for Business, Google Apps for Education o Google Apps for ISPs. Mediante este servicio, los usuarios pueden acceder a todas sus aplicaciones de Google Apps (incluida la Consola del administrador) con solo iniciar sesión una vez en una página de SSO. Google redirige a los usuarios a la página de SSO cuando intentan iniciar sesión en la Consola del administrador o en otro servicio de Google.

Google ofrece una API de SSO basada en SAML, que se puede integrar en el servidor LDAP o en otro sistema de SSO. LDAP (siglas en inglés de Lightweight Directory Access Protocol o protocolo ligero de acceso a directorios) es un protocolo de red que sirve para realizar consultas y modificar los servicios de directorio que se ejecutan en TCP/IP.

SSO admite claves y certificados públicos generados a través del algoritmo RSA o DSA. Para poder utilizar el servicio, deberás generar el conjunto de claves públicas y privadas, y un certificado X.509 que contenga la clave pública. Cuando tengas la clave o el certificado público, deberás registrarlo en Google. Para ello, solo tienes que subir la clave o el certificado a través de la consola Google Admin.

¿Cómo subo claves y certificados con la consola Google Admin?

  1. Inicia sesión en la Consola del administrador de Google
  2. Haz clic en Seguridad > Configuración avanzada. ¿Dónde puedo encontrarlo? 
  3. Haz clic en Configurar inicio de sesión único (SSO).
  4. Escribe las URL correspondientes y sube tu certificado de verificación.

Consulta la referencia sobre el inicio de sesión único para obtener más instrucciones al respecto.

Cómo generar claves y certificados para el servicio SSO de Google Apps

El método para generar claves y certificados depende, a menudo, de la plataforma de desarrollo y del lenguaje de programación. Para crear pares de claves públicas y privadas, puedes emplear OpenSSL, las herramientas Certificate Creation y Pvk2pfx en .NET, Keytool en Java y Java Cryptography Architecture. Más información

Cómo funciona el certificado de verificación

El archivo del certificado está en formato X.509 y contiene una clave pública que puede utilizar tanto algoritmos DSA como RSA. Google emplea esta clave para verificar el origen (es decir, ¿la declaración SSO procede de ti?) y la integridad (es decir, ¿se modificó la declaración durante la transmisión?) de la respuesta SAML que nos envías.

Es importante que la clave pública incluida en el certificado X.509 coincida con la clave privada que has utilizado para firmar la respuesta SAML.

Si bien no podemos ofrecer actualmente prácticas recomendadas para administradores sin certificado, la generación de certificados X.509 puede realizarse mediante el comando "openssl". Más información

Cómo funciona el elemento "Emisor" (es decir, el ID de la entidad) en la solicitud SAML

El nombre del emisor se incluye en la solicitud SAML al IdP (Identity Provider o proveedor de identidad). Puedes elegir entre incluir una entidad emisora de dominios estándar o específica. Cuando hay varios dominios que utilizan SSO con el mismo agregador de IdP, este puede analizar un emisor específico para identificar el nombre de dominio correcto para la solicitud SAML. Si no marcas la casilla para habilitar un emisor de dominio específico, Google enviará un emisor estándar (google.es) en la solicitud SAML. Si la marcas para activar esta función, Google enviará un emisor específico para tu dominio (google.es/a/tu_dominio.es), en el que deberás sustituir "tu_dominio.es" por el nombre real del dominio.

Cómo funcionan las máscaras de red

Las máscaras de red son direcciones IP representadas mediante el estándar Classless Inter-Domain Routing (CIDR). El CIDR especifica cuántos bits de una dirección IP se deben incluir. Google utiliza máscaras de red para determinar a qué direcciones IP o intervalos de IP debe asignar la función de SSO.

Es importante que cada máscara de red tenga el formato correcto: A continuación se muestra un ejemplo de IPv6:

    2001:db8::/32 (donde la barra invertida y el número después de esta representan el CIDR)
En este ejemplo, los últimos 96 bits no se toman en cuenta y esto afectaría a todas las direcciones IP en ese intervalo de red.

A continuación se muestra un ejemplo de IPv4:
    64.233.187.0/24
En este ejemplo, los últimos 8 bits (es decir, el cero) no se toman en cuenta y esto afectaría a todas las direcciones IP incluidas en el intervalo de 64.233.187.0 a 64.233.187.255.

En los dominios sin máscara de red, añade a los usuarios que no son superadministradores al Proveedor de identidad (IdP).

¿Cómo afecta la habilitación de SSO a la forma en que los usuarios inician sesión?

La página de inicio de sesión en la Consola del administrador es admin.google.com (que redirige a los usuarios a accounts.google.com), mientras que la página de inicio de sesión de un servicio de Google individual es &ltservice>.google.com/a/&lttu_dominio>.com. Cuando configuras SSO para tu dominio, el comportamiento de estas páginas dependerá de si el usuario que inicia sesión cuenta con privilegios de superadministrador y de si el dominio tiene una máscara de red.

En dominios con SSO habilitado con máscara de red:

  • Cuando los usuarios (con privilegios de superadministrador o sin ellos) intentan iniciar sesión en accounts.google.com, Google les pide sus direcciones de correo electrónico de Google completas (incluidos el nombre de usuario y el dominio) y la contraseña. Una vez que inician sesión, los dirige directamente a la Consola del administrador. Google no los redirige al servidor SSO, aunque haya máscara de red.
  • Cuando los usuarios (con privilegios de superadministrador o sin ellos) dentro de la máscara de red intentan iniciar sesión en &ltservicio>.google.com/a/&lttu_dominio>.com, Google los redirige al servidor SSO.
  • Cuando los usuarios (con privilegios de superadministrador o sin ellos) fuera de la máscara de red intentan iniciar sesión en &ltservicio>.google.com/a/&lttu_dominio>.com, Google no los redirige al servidor SSO.

En dominios con SSO habilitado sin máscara de red:

  • Cuando los superadministradores intentan iniciar sesión en accounts.google.com, Google les pide sus direcciones de correo electrónico de Google completas (incluidos el nombre de usuario y el dominio) y la contraseña. Una vez que inician sesión, los dirige directamente a la Consola del administrador. Google no los redirige al servidor SSO.
  • Cuando los usuarios que no disponen de privilegios de superadministrador (por ejemplo, los administradores delegados) intentan iniciar sesión en admin.google.com, Google los redirige al servidor SSO una vez que introducen su nombre de usuario de Google y hacen clic en Iniciar sesión.
  • Cuando los usuarios (con privilegios de superadministrador o sin ellos) intentan iniciar sesión en &ltservice>.google.com/a/&lttu_dominio>.com, Google los redirige al servidor SSO.

¿Cómo afecta el inicio de sesión único a los superadministradores?

El inicio de sesión único solo afecta a los superadministradores que intentan iniciar sesión en un servicio de Google en &ltservice>.google.com/a/&lttu_dominio>.com. No tiene ningún efecto para los superadministradores que intentan iniciar sesión en un dominio con SSO habilitado a través de admin.google.com.

 

Cuando los superadministradores intentan iniciar sesión en un dominio con SSO habilitado (con o sin máscara de red) a través de admin.google.com, deben introducir la dirección de correo electrónico de su cuenta de administrador de Google completa y la contraseña de Google asociada (no su nombre y contraseña de SSO) y hacer clic en Iniciar sesión para acceder directamente a la Consola del administrador. Google no los redirige a la página de inicio de sesión único. Esto se aplica a los intentos de inicio de sesión desde navegadores, aplicaciones para móviles (como Drive para iOS y aplicaciones de Gmail), el flujo de activación de la cuenta de Android, etc.

Cuando los superadministradores intentan iniciar sesión en otro servicio de Google desde &ltservice>.google.com/a/&ltyour_domain>.com, Google los redirige a la página de inicio de sesión único solo si intentan iniciar sesión desde dentro de la máscara de red de su dominio. Si están fuera de la máscara de red de su dominio o si su dominio no tiene una máscara de red, Google les pide su nombre de usuario y contraseña de Google.

Todavía tengo dudas

Puedes visitar la sección Preguntas frecuentes sobre el SSO para encontrar respuestas a preguntas comunes o bien leer los artículos relacionados con este servicio. Asimismo, en el mercado existen numerosos equipos de integración de sistemas o soluciones que ofrecen servicios profesionales y productos de SSO. Busca en los servicios profesionales de nuestro Google Apps Marketplace partners de Google Enterprise y otros colaboradores que proporcionan asistencia para SSO.

Lee el artículo sobre solución de problemas con el inicio de sesión único (SSO) para resolver conflictos habituales al integrar Google Apps con SSO.