Comment configurer l'authentification SSO SAML GitLab avec Google Workspace

L'authentification unique (SSO) simplifie l'authentification des utilisateurs et en améliore la sécurité, car ces derniers peuvent accéder à plusieurs applications avec un seul identifiant. Pour les organisations qui utilisent à la fois GitLab et Google Workspace, l'intégration d'une authentification unique basée sur le protocole SAML rationalise la gestion des accès et garantit une collaboration fluide au sein des équipes.

Dans ce guide, nous vous présenterons la configuration de l'authentification SAML entre Google Workspace et GitLab.com, en incluant la synchronisation automatique des groupes qui associe les groupes Google Workspace aux rôles GitLab. À la fin de ce processus, vos utilisateurs pourront se connecter à GitLab avec leurs identifiants Google, et leurs autorisations refléteront automatiquement leurs adhésions aux groupes Google.

Remarque : ce guide se concentre sur GitLab.com (version SaaS). Si vous utilisez GitLab Self-Managed, le processus de configuration diffère légèrement. Consultez la documentation officielle GitLab relative au protocole SAML pour les instances auto-gérées pour obtenir des instructions détaillées.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

• Google Workspace avec un accès super-administrateur
• GitLab.com avec un abonnement de niveau GitLab Premium ou GitLab Ultimate
• Rôle de propriétaire dans un groupe principal GitLab
• Des utilisateurs déjà existants dans Google Workspace (ils seront créés automatiquement dans GitLab lors de leur première connexion)

Comprendre l'architecture

Lorsque vous configurez l'authentification unique basée sur le protocole SAML avec la synchronisation de groupe, voici ce qui se produit :

1. Flux d'authentification : les utilisateurs accèdent à l'URL d'authentification SSO de GitLab et sont redirigés vers Google Workspace pour s'authentifier.
2. Assertion SAML : après une authentification réussie, Google envoie une réponse SAML contenant les détails de l'utilisateur et ses adhésions aux groupes.
3. Provisionnement automatique : GitLab crée le compte utilisateur (si nécessaire) et l'assigne aux groupes en fonction de ses adhésions aux groupes Google.
4. Synchronisation des autorisations : chaque fois que les utilisateurs se connectent, GitLab met à jour leurs adhésions aux groupes et leurs rôles pour qu'elles correspondent à leurs groupes Google actuels.

Cette configuration offre plusieurs avantages :

• Contrôle d'accès centralisé : vous pouvez gérer l'accès des utilisateurs via les groupes Google Workspace.
• Provisionnement automatique : les nouveaux utilisateurs obtiennent un accès à GitLab dès leur première connexion.
• Autorisations dynamiques : les rôles des utilisateurs se mettent à jour automatiquement en fonction des modifications de l'adhésion aux groupes.
• Sécurité renforcée : vous pouvez exploiter les fonctionnalités de sécurité d'authentification de Google.
• Réduction de la charge administrative : il n'est pas nécessaire de gérer manuellement les adhésions aux groupes GitLab.

Partie 1 : obtenir vos valeurs de configuration SAML GitLab

Tout d'abord, vous devrez collecter certaines informations depuis GitLab que vous utiliserez lors de la création de l'application SAML dans Google Workspace. Voici les étapes à suivre :

Étape 1 : accéder aux paramètres SAML de votre groupe GitLab

1. Connectez-vous à GitLab.com.
2. Accédez à votre groupe principal (remarque : l'authentification SSO SAML ne peut être configurée qu'au niveau du groupe principal, pas dans les sous-groupes).
3. Dans la barre latérale gauche, sélectionnez Paramètres > Authentification unique SAML.

Étape 2 : copier les URL requises

Sur la page des paramètres relatifs à l'authentification unique SAML, vous verrez trois URL importantes. Copiez-les et enregistrez-les dans un endroit accessible, vous en aurez bientôt besoin :

• URL du service consommateur d'assertion : c'est ici que Google enverra les réponses SAML.
  • Format : https://gitlab.com/groups/your-group/-/saml/callback
• Identifiant : également appelé ID de l'entité, il identifie de manière unique votre groupe GitLab.
  • Format : https://gitlab.com/groups/your-group
• URL de l'authentification unique GitLab : c'est l'URL que vos utilisateurs utiliseront pour se connecter.
  • Format : https://gitlab.com/groups/your-group/-/saml/sso

Vous allez maintenant créer une application SAML personnalisée dans Google Workspace qui se connecte à votre groupe GitLab.

Étape 3 : accéder à la console d'administration Google

1. Ouvrez un nouvel onglet de navigateur et connectez-vous à la console d'administration Google avec un compte super-administrateur.
2. Cliquez sur l'icône Menu (☰) en haut à gauche.
3. Accédez à Applications > Applications Web et mobiles.
4. Cliquez sur Ajouter une application > Ajouter une application SAML personnalisée.

Étape 4 : configurer le nom de l'application

1. Dans le champ Nom de l'application, saisissez GitLab (ou le nom de votre choix).
2. Facultatif : téléchargez un logo GitLab comme icône d'application pour faciliter l'identification de l'application.
3. Cliquez sur Continuer.

Étape 5 : télécharger les détails du fournisseur d'identité Google

Sur la page Détails du fournisseur d'identité Google, vous devrez enregistrer deux éléments :

1. URL d'authentification SSO : copiez cette URL. Elle indique à GitLab où envoyer les demandes d'authentification.
   • Format d'exemple : https://accounts.google.com/o/saml2/idp?idpid=C1234abcd
2. Certificat : cliquez sur le bouton Télécharger pour enregistrer le fichier de certificat.
   • Le fichier sera nommé comme l'exemple suivant : GoogleIDPCertificate-gitlab.pem.
   • Enregistrez ce fichier dans un endroit où vous pourrez facilement le retrouver. Vous en aurez besoin dans la section suivante.
3. Cliquez sur Continuer.

Étape 6 : configurer les détails du fournisseur de services

C'est ici que vous utiliserez les URL GitLab que vous avez copiées à l'étape 2. Saisissez les informations suivantes :

Cliquez sur Continuer une fois que vous avez terminé.

Étape 7 : configurer le mappage des attributs

Le mappage des attributs indique à Google quelles informations utilisateur envoyer à GitLab. Vous configurerez à la fois les attributs des utilisateurs de base et l'adhésion aux groupes.

Attributs de base

Ajoutez ces trois mappages d'attributs en cliquant sur Ajouter un mappage pour chacun :

Configuration de l'adhésion aux groupes

Il s'agit de la configuration critique qui permet la synchronisation automatique des groupes :

1. Faites défiler jusqu'à la section « Adhésion aux groupes (facultatif) ».
2. Sous « Groupes Google », cliquez sur « Rechercher un groupe ».
3. Recherchez et sélectionnez chaque groupe Google Workspace que vous souhaitez synchroniser avec GitLab.
   • Vous pouvez sélectionner jusqu'à 75 groupes
   • Exemples : Ingénierie, DevOps, Équipe plateforme, Équipe sécurité
4. Sous « Attribut de l'application », saisissez exactement : groups.
5. Cliquez sur Terminer.

Important : le nom de l'attribut de l'application DOIT être exactement groups (minuscules). C'est ce que GitLab s'attend à recevoir dans la réponse SAML. Toute autre valeur ou majuscule empêchera la synchronisation des groupes.

Étape 8 : activer l'application pour les utilisateurs

Votre application SAML est créée mais pas encore activée. Pour la rendre disponible aux utilisateurs :

1. Dans la console d'administration Google, repérez votre application GitLab dans la liste des applications Web et mobiles.
2. Cliquez sur l'application pour accéder aux détails.
3. Dans la barre latérale gauche, cliquez sur Accès utilisateur.
4. Sélectionnez l'une des options suivantes :
   • ACTIVÉ pour tous : active l'application pour tous les utilisateurs de votre organisation
   • ACTIVÉ pour certaines unités organisationnelles : sélectionnez des unités organisationnelles spécifiques
5. Cliquez sur Enregistrer.

Remarque : les modifications peuvent nécessiter jusqu'à 24 heures, mais prennent généralement effet en quelques minutes.

Partie 3 : convertir le certificat au format d'empreinte SHA-1

GitLab requiert une empreinte de certificat SHA-1, mais le téléchargement du certificat de Google n'inclut pas directement ce format. Vous devrez le convertir.

Étape 9 : convertir le certificat

Vous avez deux options pour convertir le certificat au format requis.

Option 1 : outil de conversion en ligne

Il s'agit d'une méthode viable si vous êtes à l'aise avec l'utilisation d'un outil tiers :

1. Localisez le fichier de certificat que vous avez téléchargé à l'étape 5 :
   • Vérifiez votre dossier Téléchargements
   • Le fichier aura un nom similaire à GoogleIDPCertificate-gitlab.pem
2. Ouvrez le fichier dans un éditeur de texte :
   • Mac : Clic droit > Ouvrir avec > TextEdit
   • Windows : Clic droit > Ouvrir avec > Bloc-notes
   • Linux : utilisez votre éditeur de texte préféré
3. Copiez TOUT le contenu du fichier, y compris l'en-tête et le pied de page :

      -----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAXqD...
(plusieurs lignes de texte encodé)
...kE7RnF6yQ==
-----END CERTIFICATE-----

    

4. Accédez à : un outil de conversion d'empreinte SHA-1 comme celui-ci.
5. Collez le contenu du certificat dans la zone de texte.
6. Sélectionnez « SHA-1 » dans le menu déroulant de l'algorithme (et non SHA-256 !).
7. Cliquez sur « Calculer l'empreinte ».
8. Copiez l'empreinte résultante : elle sera au format : XX:XX:XX:XX:XX:....

Option 2 : conversion en ligne de commande

Si vous préférez utiliser la ligne de commande :

Pour Mac, Linux ou Windows avec WSL :

      cd ~/Downloads
openssl x509 -noout -fingerprint -sha1 -inform pem -in "GoogleIDPCertificate-gitlab.pem"

    

Les données de sortie afficheront :

      SHA1 Fingerprint=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX

    

Copiez tout ce qui se trouve après SHA1 Fingerprint=.

Partie 4 : finaliser la configuration SAML GitLab

Maintenant que vous disposez de l'URL d'authentification SSO Google et de l'empreinte du certificat, vous pouvez finaliser la configuration côté GitLab.

Étape 10 : saisir les détails du fournisseur d'identité Google

Retournez à votre onglet de navigateur GitLab (Paramètres > Authentification unique SAML) et procédez comme suit :

1. URL de l'authentification SSO du fournisseur d'identité :
   • Collez l'URL de l'authentification SSO que vous avez copiée depuis Google à l'étape 5.
2. Empreinte du certificat :
   • Collez l'empreinte SHA-1 que vous avez générée à l'étape 9.
   • Vérifiez que le format est correct : 59 caractères avec des deux-points (XX:XX:XX:...).
3. Activer l'authentification SAML pour ce groupe :
   • Cochez cette case pour activer l'authentification SSO SAML.

Étape 11 : configurer les paramètres de sécurité (recommandé)

Pour renforcer la sécurité, envisagez d'activer ces options supplémentaires :

• Mettre en œuvre l'authentification unique SSO pour l'activité Web de ce groupe
  • Cette option oblige les utilisateurs à s'authentifier via SAML pour accéder à l'interface Web GitLab.
• Mettre en œuvre l'authentification unique SSO pour les activités de Git et du proxy de dépendance pour ce groupe
  • Cette option exige l'authentification SAML pour les opérations Git et l'accès au proxy de dépendances.

Cliquez sur Enregistrer les modifications pour appliquer votre configuration.

Étape 12 : tester la configuration SAML

Avant de procéder à la synchronisation des groupes, vérifiez que l'authentification SAML de base fonctionne :

1. Ouvrez une fenêtre de navigation privée ou incognito.
2. Accédez à votre URL d'authentification SSO GitLab.
   • Format : https://gitlab.com/groups/your-group/-/saml/sso
3. Vous devriez être redirigé vers la page de connexion Google.
4. Connectez-vous avec un compte Google Workspace qui a accès à l'application GitLab.
5. Après une authentification réussie, vous devriez être redirigé vers GitLab.

Si le test réussit, vous pouvez procéder à la configuration de la synchronisation des groupes.

Si le test échoue, vérifiez les points suivants :

• Vérifiez que l'empreinte du certificat est au format SHA-1 (et non SHA-256).
• Confirmez que l'URL de l'authentification SSO est correcte.
• Assurez-vous que l'utilisateur a accès à l'application SAML GitLab dans la console d'administration Google.
• Vérifiez que l'URL ACS et l'ID de l'entité correspondent exactement.

Partie 5 : configurer la synchronisation des groupes SAML

Il est maintenant temps de mapper vos groupes Google Workspace aux rôles GitLab afin que les autorisations soient automatiquement gérées en fonction de l'adhésion aux groupes.

Étape 13 : configurer le rôle d'adhésion par défaut

Comme bonne pratique de sécurité, définissez un rôle par défaut minimal pour les utilisateurs qui se connectent mais n'appartiennent à aucun groupe mappé :

1. Dans votre groupe GitLab, accédez à Paramètres > Général.
2. Développez la section Permissions et fonctionnalités du groupe.
3. Sous Rôle d'adhésion par défaut, sélectionnez Accès minimal ou Invité.
4. Cliquez sur Enregistrer les modifications.

Étape 14 : créer des liens de groupe SAML

Les liens de groupe SAML représentent les mappages entre les groupes Google Workspace et les rôles GitLab. Voici comment les créer :

1. Dans votre groupe GitLab, accédez à Paramètres > Liens de groupe SAML.
2. Cliquez sur « Ajouter un nouveau lien de groupe SAML ».

Pour chaque groupe Google Workspace que vous souhaitez synchroniser :

Nom du groupe SAML :

• Saisissez le nom exact de votre groupe Google Workspace
• Il est sensible à la casse et doit correspondre parfaitement
• Exemple : Ingénierie (et non ingénierie)
• Pour trouver le nom exact : Console d'administration Google > Annuaire > Groupes

Niveau d'accès : sélectionnez le rôle GitLab approprié :

• Accès minimal : peut voir que le groupe existe
• Invité : peut afficher les tickets et laisser des commentaires
• Rapporteur : peut récupérer le code, afficher les tickets et créer de nouveaux tickets
• Développeur : peut effectuer un push du code, créer des merge requests et gérer les tickets
• Chargé de maintenance : peut gérer les paramètres du projet et les membres
• Propriétaire : il possède le contrôle administratif complet sur le groupe

3. Cliquez sur Enregistrer.
4. Répétez ce processus pour chaque groupe Google Workspace que vous souhaitez mapper.

Remarque : les règles de synchronisation des groupes SAML sont appliquées chaque fois qu'un utilisateur se connecte. Si l'adhésion d'un utilisateur à un groupe Google correspond à une règle de synchronisation, son rôle GitLab sera automatiquement défini sur le niveau d'accès configuré, même si vous l'avez modifié manuellement. Par exemple, si vous configurez une règle de synchronisation qui accorde un accès « Chargé de maintenance » puis que vous promouvez manuellement un utilisateur à « Propriétaire », il sera automatiquement rétrogradé à « Chargé de maintenance » » lors de sa prochaine connexion SAML.

Bonnes pratiques : pour maintenir des niveaux d'accès personnalisés pour des utilisateurs spécifiques, effectuez l'une des actions suivantes :

• Utilisez la synchronisation de groupe SAML uniquement sur votre groupe principal et gérez manuellement les autorisations dans les sous-groupes.
• Créez des groupes Google séparés pour les utilisateurs qui nécessitent des autorisations élevées.
• Évitez de configurer des règles de synchronisation qui entreraient en conflit avec les affectations de rôles manuelles.

Exemple de configuration de mappage de groupes

Voici un exemple pratique de la façon dont vous pourriez structurer vos mappages de groupes :

Étape 15 : vérifier les liens de groupe

Après avoir créé tous vos liens de groupe :

1. Examinez la liste complète des liens de groupe SAML dans Paramètres > Liens de groupe SAML.
2. Vérifiez que chaque nom de groupe SAML correspond exactement au groupe Google Workspace correspondant.
3. Vérifiez que chaque niveau d'accès est approprié pour l'objectif prévu.
4. Vérifiez les fautes de frappe ou les espaces supplémentaires.

Partie 6 : tester la configuration complète

Il est maintenant temps de tester l'ensemble de la configuration, y compris la synchronisation des groupes.

Étape 16 : tester avec un utilisateur réel

Choisissez un utilisateur de test qui répond à ces critères :

• Possède un compte Google Workspace
• Est membre d'au moins un groupe Google Workspace que vous avez configuré
• A l'application SAML GitLab activée dans la console d'administration Google
• Idéalement, est quelqu'un d'autre que vous (pour garantir un test réaliste)

Pour effectuer le test :

1. Ouvrez une fenêtre de navigation privée ou incognito
2. Accédez à votre URL d'authentification SSO GitLab :
   • https://gitlab.com/groups/your-group/-/saml/sso
3. Connectez-vous avec les identifiants Google Workspace de l'utilisateur de test
4. L'utilisateur devrait être :
   • Authentifié avec succès
   • Redirigé vers GitLab
   • Ajouté automatiquement au groupe GitLab
   • Assigné au rôle approprié en fonction de son adhésion au groupe Google

Étape 17 : vérifier l'adhésion au groupe et l'attribution de rôle

Dans votre compte administrateur GitLab :

1. Accédez à votre groupe dans GitLab.
2. Sélectionnez Gestion > Membres dans la barre latérale gauche.
3. Trouvez l'utilisateur de test dans la liste des membres.
4. Vérifiez les points suivants :
   • L'utilisateur apparaît dans la liste des membres.
   • L'utilisateur a le rôle maximum correct en fonction de son/ses groupe(s) Google.
   • La colonne Source affiche un indicateur SAML.

Partie 7 : configurer l'accès aux sous-groupes (facultatif)

Pour les grandes organisations, vous souhaiterez peut-être fournir un contrôle d'accès plus granulaire en utilisant les sous-groupes GitLab. Les liens de groupe SAML peuvent être configurés à n'importe quel niveau de votre hiérarchie de groupes pour vous permettre de mapper différents groupes Google Workspace à des équipes ou projets spécifiques.

Comprendre la structure des sous-groupes GitLab

GitLab prend en charge les hiérarchies de groupes imbriqués qui peuvent refléter votre structure organisationnelle :

      acme-corp/                          ← Top-level group (SAML configured here)
├── engineering/                    ← Subgroup
│   ├── backend/                   ← Nested subgroup
│   └── frontend/                  ← Nested subgroup
├── marketing/                      ← Subgroup
└── operations/                     ← Subgroup

    

Créer des sous-groupes

Si vous devez créer des sous-groupes supplémentaires :

1. Accédez à votre groupe parent (par exemple, acme-corp).
2. Cliquez sur le bouton Nouveau sous-groupe.
3. Configurez le sous-groupe :
   • Nom du sous-groupe : nom affiché (par exemple, Ingénierie)
   • URL du sous-groupe : slug d'URL (par exemple, ingenierie)
   • Niveau de visibilité : choisissez Privé, Interne ou Public
4. Cliquez sur Créer un sous-groupe.
5. Répétez le processus pour les autres sous-groupes si nécessaire.

Configurer les liens de groupe SAML pour les sous-groupes

Suivez les étapes ci-dessous pour configurer les liens de groupe SAML pour les sous-groupes.

Ajouter de nouveaux groupes Google à l'application SAML (si nécessaire)

Si vous ajoutez de nouveaux groupes Google Workspace pour l'accès aux sous-groupes :

1. Accédez à Console d'administration Google > Applications > Applications Web et mobiles > GitLab.
2. Cliquez sur Mappage des attributs SAML.
3. Faites défiler jusqu'à « Adhésion aux groupes (facultatif) ».
4. Ajoutez vos nouveaux groupes (par exemple, équipe backend, équipe frontend).
5. Vérifiez que l'« Attribut de l'application » est toujours groups.
6. Cliquez sur Enregistrer.

Mapper les groupes Google aux sous-groupes

1. Accédez au sous-groupe spécifique dans GitLab
   • Exemple : acme-corp/engineering/backend
2. Accédez à Paramètres > Liens de groupe SAML.
3. Cliquez sur « Ajouter un nouveau lien de groupe SAML ».
4. Configurez le mappage :
   • Nom du groupe SAML : équipe backend (nom exact du groupe Google Workspace)
   • Niveau d'accès : Développeur (ou le rôle de votre choix)
5. Cliquez sur Enregistrer.

Répétez ce processus pour tous les sous-groupes et leurs groupes Google correspondants.

Exemple d'accès multi-niveaux

Voici comment les autorisations pourraient fonctionner à différents niveaux :

Groupe principal : acme-corp

Liens de groupe SAML :

• « Administrateurs de l'entreprise » → Propriétaire
• « Tous les collaborateurs » → Accès minimal

Sous-groupe : acme-corp/engineering

Liens de groupe SAML :

• « Responsables ingénierie » → Propriétaire
• « Équipe ingénierie » → Chargé de maintenance

Sous-groupe imbriqué : acme-corp/engineering/backend

Liens de groupe SAML :

• « Responsables backend » → Chargé de maintenance
• « Équipe backend » → Développeur

Héritage et combinaison des autorisations

Comprendre le comportement des autorisations est important :

• Calcul du rôle : à chaque niveau, les utilisateurs reçoivent le rôle le plus élevé de tous leurs groupes Google.
• Héritage : les autorisations plus élevées au niveau des groupes parents sont transmises aux sous-groupes enfants.
• Indépendance : chaque niveau calcule les autorisations en fonction de ses propres liens de groupe et des autorisations héritées.
• Aucune limitation : les autorisations inférieures au niveau des groupes parents ne restreignent PAS les autorisations supérieures au niveau des groupes enfants.

Exemples de scénarios :

Utilisateur A (membre de l'équipe backend uniquement) :

• acme-corp : accès minimal (depuis « Tous les collaborateurs » par défaut)
• acme-corp/engineering : accès minimal (hérité du groupe parent)
• acme-corp/engineering/backend : Développeur (depuis le mappage « Équipe backend »)

Utilisateur B (membre des responsables ingénierie et de l'équipe backend) :

• acme-corp : accès minimal (depuis « Tous les collaborateurs » par défaut)
• acme-corp/engineering : Propriétaire (depuis le mappage « Responsables ingénierie »)
• acme-corp/engineering/backend : Propriétaire (hérité du groupe parent, qui est supérieur à Développeur)

Comment fonctionne la synchronisation ?

Comprendre les mécanismes de synchronisation des groupes SAML vous aide à gérer le système efficacement.

Calendrier de synchronisation

• Synchronisation : les adhésions aux groupes se mettent à jour chaque fois qu'un utilisateur se connecte via SAML.
• Fréquence : les modifications ne sont pas continues, elles ne se produisent qu'à la connexion.
• Direction : la synchronisation est unidirectionnelle de Google Workspace vers GitLab.
• Première connexion : le compte utilisateur est créé automatiquement et les groupes sont affectés.
• Connexions suivantes : les adhésions aux groupes existantes sont mises à jour pour correspondre aux groupes Google actuels.

Priorité et combinaison des rôles

Si un utilisateur appartient à plusieurs groupes Google Workspace :

• GitLab évalue tous les groupes de l'utilisateur à chaque niveau de la hiérarchie.
• L'utilisateur obtient le rôle le plus élevé de l'un de ses groupes.
• Ce calcul se produit indépendamment à chaque niveau (groupe principal, sous-groupes, etc.).

Exemple :

• Utilisateur dans « Développeurs » (rôle Développeur) + « Responsables tech » (rôle Chargé de maintenance) → Chargé de maintenance

Modifications automatiques de rôle

Le système gère automatiquement les modifications d'adhésion :

• Utilisateur ajouté à un groupe Google : rôle mis à niveau lors de la prochaine connexion.
• Utilisateur supprimé d'un groupe Google : rôle recalculé en fonction des groupes restants lors de la prochaine connexion.
• Utilisateur supprimé de tous les groupes mappés : revient au rôle d'adhésion par défaut lors de la prochaine connexion.
• Utilisateur ajouté à des groupes supplémentaires : obtient le rôle le plus élevé de tous les groupes lors de la prochaine connexion.

Calendrier de propagation

Voici le calendrier de propagation à prendre en compte :

• Modifications Google Workspace : peuvent prendre jusqu'à 24 heures pour se propager, bien qu'elles ne prennent généralement que quelques minutes.
• Synchronisation GitLab : se produit immédiatement lorsque l'utilisateur se connecte après que les modifications Google sont actives.
• Tests : demandez aux utilisateurs de se déconnecter et de se reconnecter pour tester les modifications d'autorisations.

Comprendre le cycle de vie des utilisateurs et les cas particuliers

Que se passe-t-il lorsque vous supprimez un utilisateur de GitLab ?

Suppression des autorisations uniquement : si vous supprimez un utilisateur des projets GitLab mais laissez son compte actif et qu'il est toujours dans les groupes Google autorisés :

• Il conserve le même compte (même ID d'utilisateur et nom d'utilisateur).
• Lorsqu'il se connecte via SAML, ses adhésions aux groupes sont automatiquement restaurées.
• Il retrouve les autorisations en fonction de ses adhésions actuelles aux groupes Google.

Blocage du compte :

• Le compte existe mais est verrouillé.
• L'utilisateur ne peut pas se connecter même s'il est dans les groupes Google.
• Peut être débloqué ultérieurement, en préservant tout l'historique.

Suppression du compte :

• Le compte est définitivement supprimé.
• Si l'utilisateur se connecte à nouveau (tout en étant toujours dans les groupes Google), GitLab crée un compte entièrement nouveau.
• Le nouveau compte a un ID d'utilisateur différent sans aucune connexion avec l'ancien.

Processus de désactivation approprié

Pour révoquer définitivement l'accès d'un utilisateur, suivez ces étapes :

1. Supprimez l'utilisateur des groupes Google Workspace pour empêcher l'authentification.
2. Bloquez l'utilisateur dans GitLab pour empêcher la recréation du compte et préserver les pistes d'audit.
3. Supprimez le compte (facultatif) seulement si vous êtes certain que l'utilisateur ne reviendra pas.

Important : supprimer un utilisateur uniquement de GitLab sans le supprimer des groupes Google signifie qu'il peut simplement se reconnecter et obtenir un nouvel accès.

Propagation de l'adhésion aux groupes Google

Selon la documentation de Google, les modifications d'adhésion aux groupes peuvent prendre jusqu'à 24 heures pour se propager, bien qu'elles se produisent généralement en quelques minutes.

Scénarios de recréation de compte

Dépannage des problèmes courants

Même une configuration minutieuse peut entraîner des problèmes. Voici des solutions pour remédier aux problèmes les plus courants.

Les utilisateurs ne sont pas ajoutés aux groupes

Problème : l'utilisateur se connecte avec succès via SAML mais n'apparaît dans aucun groupe GitLab, ou apparaît seulement avec le rôle par défaut.

Causes possibles et solutions :

1. Les noms de groupe ne correspondent pas exactement
   • Vérifiez l'orthographe et les majuscules dans Google Workspace et GitLab.
   • Recherchez les espaces supplémentaires avant ou après les noms de groupe.
   • Vérifiez le nom exact dans Console d'administration Google > Annuaire > Groupes.
2. L'utilisateur n'est pas réellement dans le groupe Google
   • Vérifiez l'adhésion : Console d'administration Google > Annuaire > Groupes > Groupe > Membres.
   • N'oubliez pas que l'adhésion aux groupes imbriqués pourrait être exclue.
3. Les groupes ne sont pas configurés dans l'application SAML
   • Vérifiez que les groupes sont sélectionnés dans le mappage des attributs SAML Google.
   • Confirmez que l'« Attribut de l'application » est défini sur groups (minuscules).
   • Réalisez un test de connexion SAML pour inspecter la réponse SAML.
4. Problème de calendrier ou de cache
   • Attendez 24 heures pour que les modifications Google se propagent complètement.
   • Demandez à l'utilisateur de se déconnecter complètement de GitLab et Google.
   • Effacez le cache du navigateur et réessayez.
   • L'utilisateur doit se connecter via l'URL d'authentification unique SAML, pas la connexion GitLab normale.

L'utilisateur a un rôle incorrect

Problème : l'utilisateur a accès mais possède le mauvais niveau d'autorisation.

Causes possibles et solutions :

1. L'utilisateur appartient à plusieurs groupes
   • Rappel : les utilisateurs obtiennent le rôle le plus élevé de tous leurs groupes.
   • Vérifiez tous les groupes Google auxquels l'utilisateur appartient.
   • Examinez toutes les configurations de liens de groupe SAML à tous les niveaux.
2. Lien de groupe SAML mal configuré
   • Vérifiez le paramètre Niveau d'accès dans Paramètres > Liens de groupe SAML.
   • Recherchez les mappages de groupes en double qui pourraient entrer en conflit.
3. L'utilisateur ne s'est pas connecté depuis les modifications
   • Les rôles ne se mettent à jour que lorsque les utilisateurs se connectent via SAML.
   • Demandez à l'utilisateur de se déconnecter complètement et de se reconnecter via l'URL d'authentification SSO.
4. Autorisations héritées des groupes parents
   • Vérifiez les liens de groupe SAML dans les groupes parents.
   • N'oubliez pas que les rôles plus élevés au niveau des groupes parents sont transmis aux groupes enfant.

L'authentification SAML échoue complètement

Problème : les utilisateurs ne peuvent pas du tout se connecter ou reçoivent des messages d'erreur pendant l'authentification.

Causes possibles et solutions :

1. Empreinte de certificat incorrecte
   • Vérifiez que vous avez utilisé le format SHA-1, et non SHA-256.
   • Vérifiez que l'empreinte a le format correct avec des deux-points.
   • Régénérez un certificat en utilisant l'outil en ligne ou la commande OpenSSL.
2. URL d'authentification unique incorrecte
   • Vérifiez à nouveau l'URL d'authentification unique copiée depuis Google.
   • Assurez-vous qu'il n'y a pas d'espaces ou de caractères supplémentaires.
3. Incompatibilité de l'URL ACS ou de l'ID de l'entité
   • Vérifiez que l'URL ACS dans la console d'administration Google correspond exactement à GitLab.
   • Confirmez que l'ID de l'entité correspond entre les deux systèmes.
4. L'utilisateur n'a pas d'accès à l'application
   • Vérifiez les paramètres d'accès utilisateur dans la console d'administration Google.
   • Vérifiez que l'unité organisationnelle de l'utilisateur a l'application activée.
   • Confirmez que l'application est activée pour les utilisateurs appropriés.
5. Certificat expiré
   • Vérifiez les dates de validité du certificat.
   • Téléchargez un nouveau certificat si nécessaire.

Attribut de groupe manquant dans la réponse SAML

Problème : les utilisateurs peuvent se connecter, mais la synchronisation des groupes ne fonctionne pas.

Causes possibles et solutions :

1. Groupes non sélectionnés dans la configuration Google
   • Retournez à Console d'administration Google > Applications > GitLab > Mappage des attributs.
   • Vérifiez que les groupes sont sélectionnés sous « Adhésion aux groupes ».
   • Confirmez que l'« Attribut de l'application » est exactement groups (minuscules).
2. L'utilisateur n'est dans aucun groupe configuré
   • Seuls les groupes auxquels l'utilisateur appartient sont envoyés dans la réponse SAML.
   • Ajoutez l'utilisateur à au moins un groupe sélectionné pour effectuer un test.
3. La configuration ne s'est pas propagée
   • Attendez jusqu'à 24 heures pour que les modifications prennent effet.
   • Essayez de vous déconnecter de la console d'administration Google et de vous reconnecter.
4. Faute de frappe dans le nom de l'attribut de l'application
   • Le nom de l'attribut doit être exactement groups (minuscules).
   • Une lettre majuscule ou un espace supplémentaire cassera la fonctionnalité.

Bonnes pratiques pour gérer la synchronisation de groupe SAML

Suivez ces recommandations pour maintenir une configuration sécurisée et efficace.

Bonnes pratiques de sécurité

1. Maintenir un accès d'urgence
   • Conservez au moins un compte Propriétaire qui utilise l'authentification par mot de passe (pas SAML).
   • Vous aurez un accès d'urgence si la configuration SAML ne fonctionne plus.
   • Stockez ces identifiants de façon sécurisée.
2. Utiliser le principe du moindre privilège
   • Définissez l'adhésion par défaut sur Accès minimal.
   • Accordez uniquement des autorisations plus élevées via des mappages de groupes explicites.
   • Examinez et auditez régulièrement les adhésions aux groupes.
3. Activer les options d'application
   • Activez les options « Mettre en œuvre l'authentification unique SSO ».
   • Cela empêche les utilisateurs de contourner l'authentification unique.
   • Les exceptions doivent être rares et bien documentées.
4. Effectuer des audits de sécurité réguliers
   • Examinez tous les trimestre les adhésions aux groupes Google Workspace.
   • Vérifiez chaque année les mappages de liens de groupe SAML.
   • Surveillez les journaux d'audit GitLab pour détecter les schémas d'accès inhabituels.

Résumé et prochaines étapes

Félicitations ! Vous avez configuré avec succès l'authentification unique basée sur le protocole SAML et la synchronisation automatique des groupes entre Google Workspace et GitLab. Votre configuration offre désormais :

• Une authentification transparente : les utilisateurs se connectent avec leurs identifiants Google Workspace.
• Un provisionnement automatique : les comptes utilisateur sont créés lors de la première connexion sans intervention manuelle.
• Des autorisations dynamiques : les adhésions aux groupes et les rôles se mettent à jour automatiquement en fonction des groupes Google Workspace.
• Un contrôle d'accès centralisé : gérez tous les accès via vos groupes Google Workspace existants.
• Une sécurité renforcée : exploitez l'infrastructure d'authentification de Google et appliquez des politiques cohérentes.
• Une réduction de la charge administrative : éliminez la gestion manuelle des utilisateurs et des autorisations dans GitLab.

Fonctionnement correct

Lorsque les utilisateurs accèdent à GitLab :

1. Ils accèdent à votre URL d'authentification SSO GitLab.
2. Ils s'authentifient avec leurs identifiants Google Workspace.
3. Ils sont automatiquement ajoutés aux groupes GitLab appropriés.
4. Ils reçoivent des autorisations basées sur leurs adhésions aux groupes Google.
5. Leurs autorisations se mettent à jour chaque fois qu'ils se connectent.

Ressources supplémentaires

• Documentation concernant l'authentification unique basée sur le protocole SAML de GitLab
• Documentation concernant la synchronisation des groupes SAML GitLab
• Configuration de l'application SAML sur Google Workspace
• Outil d'empreinte de certificat SAML