Questions fréquentes sur l'authentification unique SAML

Quelle version du SAML est compatible avec l'API SSO ?

Nous acceptons actuellement SAML v2.0. Consultez http://www.oasis-open.org/specs/index.php#samlv2.0 pour en savoir plus sur la norme SAML v2.0.

L'authentification unique SAML fonctionne-t-elle avec POP3 ou IMAP ?

Non, SAML ne fonctionne qu'avec les applications Web Google Workspace.

L'authentification unique SAML fonctionne-t-elle avec le flux Atom Gmail ?

Non, le flux Atom Gmail utilise l'authentification HTTP de base.

L'authentification unique SAML fonctionne-t-elle avec AuthSub ?

Oui, SAML fonctionne avec AuthSub.

Puis-je remplacer DSA par RSA pour la mise en œuvre de l'authentification unique ?

Oui, vous pouvez choisir d'utiliser l'algorithme de chiffrement RSA ou DSA. Nous acceptons les deux.

Comment puis-je générer le certificat de validation requis pour l'authentification unique ?

Vous pouvez générer des certificats X509 à l'aide de la commande openssl. Pour en savoir plus, consultez Générer des clés et des certificats pour le SSO.

Si notre domaine met en œuvre l'authentification unique, est-il encore possible de se connecter directement à Google ?

Non. Une fois l'authentification unique mise en œuvre, les utilisateurs finaux du domaine ne peuvent plus se connecter directement à Google. Les super-administrateurs peuvent toujours se connecter au panneau de configuration Google (par exemple, http://www.google.com/a/exemple.com).

Comment supprimer le cookie de session non persistant qui identifie un utilisateur au cours d'une session du navigateur (par exemple, lors de la déconnexion) ?

Une fois l'authentification SAML réussie, Google définit un cookie de session pour identifier la session d'un utilisateur. Lorsque l'utilisateur se déconnecte explicitement (par exemple, en cliquant sur le bouton de déconnexion), ce cookie doit être détruit. Si votre implémentation implique une gestion de session persistante (fonctionnalité "Se souvenir de moi sur cet ordinateur"), vous devrez peut-être contrôler comment et quand ce cookie est détruit. Une fois l'utilisateur déconnecté, Google le redirige vers votre servlet de déconnexion. Dans votre servlet de déconnexion, vous pouvez présenter à l'utilisateur des options qui peuvent déterminer si le cookie de session doit être supprimé ou non.

Pourquoi l'URL de la page de modification du mot de passe ne fonctionne-t-elle pas ?

Il faut environ une heure pour que les modifications apportées à l'URL de la page de modification du mot de passe dans les paramètres SSO soient prises en compte.

Pourquoi le formulaire HTML de réponse SAML fonctionne-t-il dans Firefox, mais pas dans Internet Explorer ?

Il est possible qu'Internet Explorer n'interprète pas correctement RelayState. Internet Explorer interprète "&ltmpl" comme "<mpl". Pour éviter cela, les caractères spéciaux XML doivent être échappés dans RelayState. Remplacez { &, <, >, ', " } par { &amp;, <, >, &apos;, &quot; }.

Comment autoriser les utilisateurs à accéder à la page d'accueil des partenaires sans authentification ?

Consultez cet article dans le groupe de discussion pour un exemple de réponse SAML.

Quel attribut "Recipient" doit être spécifié dans la réponse SAML ?

D'après la section 4.1.4.2 de la spécification des profils SAML 2.0, l'attribut "Recipient" doit être identique à l'URL du service ACS (Assertion Consumer Service), en gras ci-après :

<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>

Consultez les questions ci-dessous pour savoir comment ajouter le destinataire à la réponse SAML.

Comment s'assurer que le fournisseur d'identité tiers spécifie l'attribut "Recipient" ?

Si votre fournisseur d'identité commercial ou Open Source autorise SAML 2.0, il devrait déjà spécifier l'attribut "Recipient" approprié. Si l'un des messages d'erreur ci-dessus s'affiche, cela signifie que l'attribut de destinataire est incorrect. Si tel est le cas, envoyez au fournisseur ou au mainteneur du logiciel le lien vers cette page.

Avec l'authentification unique, les utilisateurs peuvent-ils s'authentifier à l'aide de l'URL de connexion au panneau de configuration de l'administrateur ?

Oui. L'authentification unique (SSO) basée sur SAML vous permet de transférer l'autorité de connexion Google Workspace vers votre propre logiciel de fournisseur d'identité (par exemple, un portail de connexion existant). Votre logiciel contrôle et gère l'authentification de vos comptes utilisateur. Google Workspace redirige les tentatives de connexion vers votre portail SSO. Il est cependant important de noter que vos administrateurs sont toujours en mesure de gérer ces services à l'aide de l'URL de connexion administrateur de la console d'administration Google (https://www.google.com/a/exemple.com). Ainsi, vous pouvez intervenir en cas de problème du portail d'authentification unique ou si une mise à jour est nécessaire.

Que signifie le message d'erreur : "Ce service est inaccessible, car votre demande de connexion ne contient aucune information sur le destinataire." ?

Cela signifie que l'attribut Recipient de la réponse SAML n'est pas spécifié.

Que signifie le message d'erreur : "Ce service est inaccessible, car les informations sur le destinataire contenues dans votre demande de connexion sont incorrectes." ?

Cela signifie que l'attribut Recipient dans la réponse SAML ne correspond pas à l'URL du service ACS (Assertion Consumer Service).

Que signifie le message d'erreur "Ce compte est inaccessible, car les identifiants de connexion n'ont pas pu être vérifiés" ?

Cela signifie généralement que la clé privée utilisée pour signer la réponse SAML ne correspond pas au certificat de clé publique enregistré dans Google Workspace. Veuillez importer le certificat dans les paramètres SSO du panneau de configuration, puis réessayer.