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.

¿El SSO de SAML funciona con el feed de Atom de Gmail?

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

¿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 ambos.

¿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 Genera claves y certificados para el SSO.

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

No, con el SSO implementado, los usuarios finales del dominio no pueden acceder directamente a Google. Los administradores avanzados aún pueden acceder al panel de control de Google (p. ej., http://www.google.com/a/example.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 se sale de la cuenta)?

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 la sesión de forma explícita (p.ej., haciendo clic en el botón para salir), se debe destruir esta cookie. Si tu implementación incluye la administración de sesiones persistentes (función "recordarme en esta computadora"), es posible que debas controlar cómo y cuándo se destruye esta cookie. Cuando se sale de la sesión, Google redirecciona al servlet de salida. En tu servlet de salida, puedes presentarle al usuario algunas opciones que podrían determinar si se debe borrar o no la cookie de sesión.

¿Por qué no funciona la URL para cambiar la contraseña?

Los cambios en la URL para cambiar la 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 RelayState. Internet Explorer interpreta "&ltmpl" como "<mpl". Para evitar que esto suceda, se deben escapar los caracteres especiales de XML en el 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 discusión para ver un ejemplo de SAMLResponse.

¿Cuál 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 siguientes preguntas 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 este es el caso, comunícate con el proveedor o el encargado de mantenimiento del software y envíale el vínculo a esta página.

Con el SSO, ¿mis usuarios pueden autenticarse con la URL de acceso del 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á los intentos 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 actualizarse.

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

Significa que a la respuesta de SAML le falta un atributo Recipient obligatorio.

¿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"?

Significa que el atributo Recipient de la respuesta de SAML no coincide con la URL del Servicio de aserción del consumidor (ACS).

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

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