Configurar 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 (SSO) a clientes que usan Google Apps for Work, 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 de administración) 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 de administración 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 mi 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 sesión único para obtener más instrucciones.

¿Cómo genero 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" (por ejemplo, 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 habilitar 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 de administración 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 <servicio>.google.com/a/<tu_dominio>.com. Cuando configuras SSO en 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 o sin privilegios de superadministrador) 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 de administración. Google no los redirige al servidor SSO, aunque haya máscara de red.
  • Cuando los usuarios (con o sin privilegios de superadministrador) dentro de la máscara de red intentan iniciar sesión en <servicio>.google.com/a/<tu_dominio>.com, Google los redirige al servidor SSO.
  • Cuando los usuarios (con o sin privilegios de superadministrador) fuera de la máscara de red intentan iniciar sesión en <servicio>.google.com/a/<tu_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 (con o sin privilegios de superadministrador) intentan iniciar sesión en accounts.google.com, Google 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 o sin privilegios de superadministrador) intentan iniciar sesión en <servicio>.google.com/a/<tu_dominio>.com, Google los redirige al servidor SSO.
¿Cómo afecta el inicio de sesión único a los superadministradores?

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.

Una vez habilitado el SSO en un dominio, cuando se introduzca la dirección de correo electrónico de un superadministrador, en lugar de solicitar el nombre de usuario y la contraseña, se redirigirá a la página de inicio de sesión especificada en la Consola de administración. Cuando esto ocurre, los superadministradores no pueden iniciar sesión hasta que hayan pasado 48 horas como máximo. Una vez transcurrido este plazo, los superadministradores omitirán correctamente este ajuste. Esto ocurre para cualquier cuenta en la que se habilite el inicio de sesión único.

Cuando los superadministradores inician sesión en el cliente de sincronización de Drive, omiten el inicio de sesión único.

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 de administración. 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 inician sesión en otro servicio de Google en <servicio>.google.com/a/<tu_dominio>.com, Google solo los redirige a la página de inicio de sesión único si inician sesión desde 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.

Los clientes como Gmail App for iOS, Drive App for iOS, Chrome Browser Sync, la configuración de Android, etc. utilizan la autenticación de Google. Cuando intentas iniciar sesión a través de esos clientes, Google te pide que indiques tu dirección de correo electrónico completa de Google (incluido el nombre de usuario y el dominio). Se te dirigirá directamente a la aplicación una vez que hayas iniciado sesión. Google no te redirige al servidor SSO, independientemente de la máscara de red.

¿Cómo configuro el inicio de sesión único en dispositivos Chrome? 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 los servicios profesionales en nuestra página Google Apps Marketplace para partners de Google for Work y terceros que proporcionen asistencia para inicio de sesión único.

Lee Solución de incidencias con el inicio de sesión único (SSO) para resolver los problemas habituales que se detectan al integrar Google Apps con el inicio de sesión único.