Vous pouvez configurer votre compte Cloud Identity ou Google Workspace pour utiliser l'authentification unique (single sign-on, SSO). Lorsque vous activez l'authentification unique, les utilisateurs ne sont pas invités à saisir un mot de passe lorsqu'ils tentent d'accéder aux services Google. À la place, ils sont redirigés vers un fournisseur d'identité externe (ou IdP, Identity provider) pour s'authentifier.
L'utilisation de l'authentification unique peut offrir plusieurs avantages :
- Elle améliore l'expérience des utilisateurs, car ils peuvent s'authentifier à l'aide de leurs identifiants existants et n'ont plus besoin de les saisir aussi souvent.
- Vous vous assurez que votre fournisseur d'identité existant reste le système d'enregistrement pour l'authentification des utilisateurs.
- Vous n'avez pas besoin de synchroniser les mots de passe avec Cloud Identity ou Google Workspace.
Pour utiliser l'authentification unique, un utilisateur doit disposer d'un compte utilisateur Cloud Identity ou Google Workspace et d'une identité correspondante dans l'IdP externe. L'authentification unique est donc généralement utilisée conjointement avec une source externe faisant autorité qui provisionne automatiquement des utilisateurs à Cloud Identity ou à Google Workspace.
Processus d'authentification unique
Cloud Identity et Google Workspace sont compatibles avec le langage SAML 2.0 (Security Assertion Markup Language) pour l'authentification unique. SAML est une norme Open Source qui échange des données d'authentification et d'autorisation entre un fournisseur d'identité SAML et des fournisseurs de services SAML. Lorsque vous utilisez l'authentification unique pour Cloud Identity ou Google Workspace, votre fournisseur d'identité externe est le fournisseur d'identité SAML et Google est le fournisseur de services SAML.
Google met en œuvre la liaison HTTP POST SAML 2.0. Cette liaison spécifie la manière dont les informations d'authentification sont échangées entre le fournisseur d'identité (IdP, Identity Provider) SAML et le fournisseur de services SAML. Le schéma suivant illustre le fonctionnement de ce processus lorsque vous utilisez SSO pour accéder à la console Google Cloud.
- Pointez votre navigateur vers la console Google Cloud (ou toute autre ressource Google nécessitant une authentification).
- Comme vous n'êtes pas encore authentifié, la console Google Cloud redirige votre navigateur vers Google Sign-In.
- Google Sign-In renvoie une page de connexion (Sign-In) vous invitant à saisir votre adresse e-mail.
- Vous saisissez votre adresse e-mail, puis vous envoyez le formulaire.
- Google Sign-In recherche le compte Cloud Identity ou Google Workspace associé à votre adresse e-mail.
Étant donné que l'authentification unique est activée pour le compte Cloud Identity ou Google Workspace associé, Google Sign-In redirige le navigateur vers l'URL du fournisseur d'identité externe configuré. Avant d'émettre la redirection, elle ajoute deux paramètres à l'URL,
RelayState
etSAMLRequest
.RelayState
contient un identifiant que le fournisseur d'identité externe devra renvoyer ultérieurement.SAMLRequest
contient la requête d'authentification SAML, un document XML qui a été compressé en format deflate, encodé en base64 et encodé au format URL. Sous forme décodée, la requête d'authentification SAML ressemble à ceci :<samlp:AuthnRequest ProviderName="google.com" IsPassive="false" AssertionConsumerServiceURL="https://www.google.com/a/example.com/acs" ...> <saml:Issuer xmlns:saml="...">google.com</saml:Issuer> <samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/> </samlp:AuthnRequest>
Cet exemple de requête demande au fournisseur d'identité externe d'authentifier l'utilisateur, de créer une assertion SAML pour l'audience
google.com
et de l'envoyer au service consommateur d'assertion (assertion consumer service, ACS) à l'adressehttps://www.google.com/a/example.com/acs
.Le domaine intégré à l'URL ACS (
example.com
) correspond au domaine principal de votre compte Cloud Identity ou Google Workspace.Si vous utilisez la fonctionnalité d'émetteur spécifique au domaine lorsque vous configurez l'authentification unique, l'émetteur est
google.com/a/DOMAIN
au lieu degoogle.com
, oùDOMAIN
est le domaine principal de votre compte Cloud Identity ou Google Workspace.Les étapes effectuées par le fournisseur d'identité externe pour l'authentification dépendent du fournisseur d'identité et de sa configuration. Il peut s'agir d'une boîte de dialogue de connexion, d'une invite MFA ou d'une invite d'empreinte digitale. Une fois ces étapes terminées, l'échange SAML se poursuit :
Le fournisseur d'identité externe renvoie une page HTML spécialement conçue pour obliger votre navigateur à envoyer immédiatement une requête HTTP POST à l'URL ACS. Cette requête contient deux paramètres :
RelayState
, qui contient la valeur initialement transmise au fournisseur d'identité dans la requête d'authentification SAML.SAMLResponse
, qui contient l'assertion SAML encodée en base64. L'assertion SAML est un document XML indiquant que le fournisseur d'identité a réussi à authentifier l'utilisateur. Sous forme décodée, l'assertion SAML se présente comme suit :<samlp:Response ...> ... <Assertion x...> <Issuer>https://idp.example.org/</Issuer> <Signature ...> ... </Signature> <Subject> <NameID Format="...:nameid-format:emailAddress">bob@example.org</NameID> ... </Subject> <Conditions NotBefore="..." NotOnOrAfter="..."> <AudienceRestriction> <Audience>google.com</Audience> </AudienceRestriction> </Conditions> <AttributeStatement> ... </AttributeStatement> <AuthnStatement AuthnInstant="..." ...> <AuthnContext> <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef> </AuthnContext> </AuthnStatement> </Assertion> </samlp:Response>
Cet exemple d'assertion a été émis pour l'audience
google.com
(correspondant à l'émetteur de la requête d'authentification SAML) et indique que le fournisseur d'identitéhttps://idp.example.org/
a authentifié l'utilisateurbob@example.org
.L'assertion SAML contient également une signature numérique. Le fournisseur d'identité crée cette signature à l'aide de la clé privée d'un certificat de signature. La clé privée n'est connue que du fournisseur d'identité. La clé publique correspondante fait partie de la configuration de l'authentification unique dans Cloud Identity ou Google Workspace et est partagée avec Google Sign-In.
L'assertion SAML contient également une signature numérique permettant au fournisseur de services SAML de vérifier l'authenticité de l'assertion.
Le navigateur publie l'assertion SAML sur le point de terminaison ACS Google.
Le point de terminaison ACS valide la signature numérique de l'assertion SAML. Cette vérification permet de s'assurer que l'assertion provient du fournisseur d'identité externe de confiance et qu'elle n'a pas été altérée. Si la signature est valide, le point de terminaison ACS analyse le contenu de l'assertion, ce qui inclut la vérification des informations sur l'audience et la lecture de l'attribut
NameID
.Le point de terminaison ACS recherche votre compte utilisateur en faisant correspondre l'élément
NameID
de l'assertion SAML à l'adresse e-mail principale de l'utilisateur. Le point de terminaison démarre ensuite une session.En fonction des informations encodées dans le paramètre
RelayState
, le point de terminaison détermine l'URL de la ressource à laquelle vous aviez initialement demandé accès, puis vous êtes redirigé vers la console Google Cloud.
Connexion initiée par le fournisseur d'identité (IdP)
Le processus décrit dans la section précédente est parfois appelé connexion initiée par le fournisseur de services, car le processus commence au niveau du fournisseur de services, qui est, dans l'exemple précédent, la console Google Cloud.
SAML définit également un flux alternatif appelé connexion initiée par le fournisseur d'identité, qui commence avec le fournisseur d'identité. Google ne prend pas en charge ce flux, mais vous pouvez obtenir des résultats similaires en utilisant l'URL suivante pour initier la connexion par fournisseur de services :
https://www.google.com/a/DOMAIN/ServiceLogin?continue=https://console.cloud.google.com/
Dans cet exemple, DOMAIN
est le domaine principal de votre compte Cloud Identity ou Google Workspace.
Authentification multifacteur
Pour protéger les comptes utilisateur contre les accès non autorisés, vous pouvez demander aux utilisateurs de fournir un deuxième facteur lors de l'authentification. Il existe deux manières de mettre en œuvre l'authentification multifacteur lorsque vous utilisez l'authentification unique :
- Si votre fournisseur d'identité externe est compatible avec l'authentification multifacteur, vous pouvez faire en sorte qu'il effectue l'authentification multifacteur lors du processus d'authentification SAML. Dans ce cas, aucune configuration supplémentaire n'est requise dans Cloud Identity ou Google Workspace.
- Si votre fournisseur d'identité n'est pas compatible avec l'authentification multifacteur, vous pouvez configurer votre compte Cloud Identity ou Google Workspace pour qu'il effectue la validation en deux étapes immédiatement après qu'un utilisateur s'authentifie avec le fournisseur d'identité externe.
Mise en réseau
Dans la liaison de redirection HTTP SAML 2.0, l'IdP et le fournisseur de services ne communiquent pas directement. Au lieu de cela, toutes les communications sont transmises via le navigateur de l'utilisateur, comme indiqué dans le diagramme suivant :
Compte tenu de cette architecture, il n'est pas nécessaire que le fournisseur d'identité soit exposé sur Internet ou qu'il dispose d'un accès à Internet tant que les utilisateurs peuvent y accéder depuis le réseau de votre entreprise.
Configuration du fournisseur d'identité externe
Cloud Identity et Google Workspace vous permettent de configurer l'authentification unique en utilisant les fonctionnalités suivantes :
Profils SAML : vous pouvez créer un profil SAML pour chaque IdP que vous souhaitez intégrer. Pour chaque utilisateur, groupe ou unité organisationnelle de votre compte Cloud Identity ou Google Workspace, vous déterminez ensuite s'il doit utiliser SSO, et le profil SAML qu'il doit utiliser.
Profils SSO de l'organisation classique : vous pouvez créer un profil organisationnel unique à intégrer à un seul IdP. Pour chaque utilisateur, groupe ou unité organisationnelle de votre compte Cloud Identity ou Google Workspace, vous décidez ensuite si SSO doit être utilisé ou non.
La meilleure façon de configurer votre IdP varie selon que vous utilisez des profils SAML ou des profils organisationnels classiques. Le tableau suivant récapitule les paramètres qui doivent généralement être configurés dans un fournisseur d'identité externe pour garantir la compatibilité.
Configuration | Paramètre requis pour les profils organisationnels classiques |
Paramètre requis pour les profils SAML |
Remarques |
---|---|---|---|
ID du nom | Adresse e-mail principale de l'utilisateur | Adresse e-mail principale de l'utilisateur | |
Format de l'ID du nom | urn:oasis:names:tc:SAML:1.1: |
urn:oasis:names:tc:SAML:1.1: |
|
ID d'entité |
Si la fonctionnalité d'émetteur spécifique au domaine est activée :
Si la fonctionnalité d'émetteur spécifique au domaine est désactivée (par défaut) :
Utilisez la fonctionnalité d'émetteur spécifique au domaine si vous souhaitez intégrer plusieurs comptes Cloud Identity ou Google Workspace au même IdP. Sinon, laissez-le désactivé. |
ID d'entité unique de votre profil SAML. Selon la date de création de votre profil SAML, l'ID d'entité respecte l'un des formats suivants :
|
|
Format d'URL ACS (ou URL de redirection) | https://www.google.com/a/* |
URL ACS unique de votre profil SAML. Selon la date de création de votre profil SAML, l'URL utilise l'un des formats suivants :
|
|
Demander une signature | Désactivé | Désactivé | Les requêtes d'authentification SAML émises par Google Sign-In ne sont jamais signées. |
Signature d'assertion | Activé | Activé | Les assertions SAML doivent être signées pour permettre à Google Sign-In de vérifier leur authenticité. Lorsque vous configurez SSO dans la console d'administration, vous devez importer la clé publique de la paire de clés de signature de jetons. |
Chiffrement d'assertion | Désactivé | Désactivé | |
Algorithme de signature | RSA-SHA256 | RSA-SHA256 | RSA-SHA256 est parfois abrégé en RS256 |
Étapes suivantes
- Consultez la section sur les architectures de référence pour l'intégration à un fournisseur d'identité externe.
- Apprenez à configurer le provisionnement des comptes et l'authentification unique avec Azure AD ou Active Directory.
- Consultez les bonnes pratiques pour fédérer Google Cloud avec un fournisseur d'identité externe.