Preguntas frecuentes sobre el SSO basado en SAML

¿Qué versión de SAML admite la API de SSO?

Actualmente, admitimos SAML v2.0. Visita http://www.oasis-open.org/specs/index.php#samlv2.0 para obtener detalles sobre el estándar SAML v2.0.

¿El SSO de SAML funciona con POP3 o IMAP?

No, SAML solo funciona con las aplicaciones web de Google Workspace.

¿Funciona el SSO de SAML con el feed Atom de Gmail?

No, el feed Atom de Gmail usa la autenticación HTTP básica.

¿El SSO de SAML funciona con AuthSub?

Sí, SAML funciona con AuthSub.

¿Podemos usar RSA en lugar de DSA para la implementación del inicio de sesión único?

Sí, puedes elegir usar el algoritmo de encriptación RSA o DSA. Aceptamos ambas.

¿Cómo puedo generar el certificado de verificación necesario para el SSO?

Puedes generar certificados X509 con el comando openssl. Para obtener más detalles, consulta Cómo generar claves y certificados para el SSO.

Si nuestro dominio implementa el SSO, ¿podemos acceder a Google directamente?

No. Con el SSO implementado, los usuarios finales del dominio no pueden acceder a Google directamente. Los administradores avanzados aún pueden acceder al panel de control de Google (p. ej., http://www.google.com/a/ejemplo.com).

¿Cómo se puede borrar la cookie de sesión no persistente que identifica a un usuario durante una sesión del navegador (p.ej., cuando cierra la sesión)?

Después de una autenticación exitosa a través de SAML, Google establece una cookie de sesión para identificar la sesión de un usuario. Cuando el usuario sale de forma explícita (p.ej., haciendo clic en el botón de salir), se debe destruir esta cookie. Si tu implementación implica la administración de sesiones persistentes (función "Recordarme en este equipo"), es posible que debas controlar cómo y cuándo se destruye esta cookie. Cuando se cierra la sesión, Google redirecciona a tu servlet de cierre de sesión. En tu servlet de cierre de sesión, puedes presentarle al usuario algunas opciones que podrían determinar si se debe borrar la cookie de sesión o no.

¿Por qué no funciona la URL de cambio de contraseña?

Los cambios en la URL de cambio de contraseña en la configuración de SSO tardan aproximadamente una hora en aplicarse.

¿Por qué el formulario HTML de SAMLResponse funciona en Firefox, pero no en Internet Explorer?

Esto puede deberse a que Internet Explorer interpreta de forma incorrecta el parámetro RelayState. Internet Explorer interpreta "&ltmpl" como "<mpl". Para evitar que esto suceda, los caracteres especiales de XML deben incluir un escape en RelayState. Cambia { &, <, >, ', "} por { &amp;, <, >, &apos;, &quot;}.

¿Cómo puedo permitir que los usuarios vean la página de inicio del socio sin autenticarse?

Consulta este tema en el grupo de debate para ver un ejemplo de SAMLResponse.

¿Qué es el atributo Recipient que se requiere en la respuesta de SAML?

Según la sección 4.1.4.2 de la especificación de perfiles de SAML 2.0, el atributo Recipient debe ser igual a la URL del servicio de confirmación de aserciones (ACS). Se encuentra aquí:

<samlp:Response ...>
  <saml:Assertion ...>
    <saml:Subject>
      <saml:NameID ...>user@domain.com</saml:NameID>
      <saml:SubjectConfirmation ...>
        <saml:SubjectConfirmationData Recipient="https://www.google.com/a/domain.com/acs" .../>
      </saml:SubjectConfirmation>
    </saml:Subject>
  </saml:Assertion>
</samlp:Response>

Consulta las preguntas a continuación para saber cómo puedes agregar el destinatario a la respuesta de SAML.

¿Cómo me aseguro de que mi proveedor de identidad externo especifique el atributo Recipient correcto?

Si tu proveedor de identidad comercial o de código abierto admite SAML 2.0, ya debería especificar el atributo Recipient correcto. Si recibes uno de los mensajes de error anteriores, significa que el atributo Recipient es incorrecto. Si es así, comunícate con el proveedor o el encargado del mantenimiento del software y envíales el vínculo a esta página.

Con el SSO, ¿mis usuarios pueden autenticarse con la URL de acceso al panel de control del administrador?

Sí. El inicio de sesión único (SSO) basado en SAML te permite transferir la autoridad de acceso de Google Workspace a tu propio software de proveedor de identidad (por ejemplo, un portal de acceso existente). Tu software controla y administra la autenticación de tus cuentas de usuario, y Google Workspace redireccionará un intento de acceso a tu portal de SSO. Sin embargo, es importante recordar que los administradores podrán seguir administrando estos servicios con la URL de acceso de administrador de la Consola del administrador de Google (https://www.google.com/a/example.com). Esto te brinda flexibilidad si tu portal de SSO tiene un problema o necesita una actualización.

¿Qué significa el mensaje de error "No se puede acceder a este servicio porque tu solicitud de acceso no contiene información del destinatario"?

Esto significa que falta un atributo Recipient obligatorio en la respuesta de SAML.

¿Qué significa el mensaje de error "No se puede acceder al servicio porque tu solicitud de acceso contiene información de destinatario no válida"?

Esto significa que el atributo Recipient en la respuesta de SAML no coincide con la URL del servicio de confirmación de aserciones (ACS).

¿Qué significa el mensaje de error "No se puede acceder a la cuenta porque no se pudieron verificar las credenciales de acceso"?

Por lo general, esto significa que la clave privada que se usó para firmar el SAMLResponse no coincide con el certificado de clave pública que Google Workspace tiene registrado. Sube el certificado a la configuración de SSO en el panel de control y vuelve a intentarlo.