doc-locale/fr-fr/administration/settings/scim_setup.md
{{< details >}}
{{< /details >}}
Vous pouvez utiliser le standard ouvert System for Cross-domain Identity Management (SCIM) pour automatiquement :
L'API SCIM GitLab interne implémente une partie du protocole RFC7644.
Si vous êtes un utilisateur de GitLab.com, consultez la configuration de SCIM pour les groupes GitLab.com.
Prérequis :
Pour configurer GitLab SCIM :
GitLab prend en charge SCIM avec plusieurs fournisseurs d'identité. D'autres fournisseurs d'identité peuvent encore fonctionner avec GitLab, mais ils n'ont pas été testés et ne sont pas pris en charge. Pour obtenir de l'aide avec un fournisseur non pris en charge, contactez directement le fournisseur. Le support GitLab peut aider à examiner les entrées de journal associées.
L'application SAML créée lors de la configuration de l'authentification unique pour Okta doit être configurée pour SCIM.
Prérequis :
Pour configurer Okta pour SCIM :
{{< history >}}
{{< /history >}}
Prérequis :
L'application SAML créée lors de la configuration de l'authentification unique pour Azure Active Directory doit être configurée pour SCIM. Pour un exemple, consultez la configuration exemple.
[!note] Vous devez configurer le provisionnement SCIM exactement comme indiqué dans les instructions suivantes. En cas de mauvaise configuration, vous rencontrerez des problèmes avec le provisionnement des utilisateurs et la connexion, qui nécessitent beaucoup d'efforts pour être résolus. Si vous avez des difficultés ou des questions concernant une étape, contactez le support GitLab.
Pour configurer Microsoft Entra ID, vous configurez :
Dans votre application, accédez à l'onglet Provisioning et sélectionnez Démarrer.
Définissez le Provisioning Mode sur Automatic.
Remplissez les Admin Credentials en utilisant la valeur de :
Sélectionnez Test Connection.
Si le test réussit, enregistrez votre configuration.
Si le test échoue, consultez le dépannage pour tenter de résoudre le problème.
Sélectionnez Enregistrer.
Après l'enregistrement, les sections Mappings et Paramètres apparaissent.
Sous la section Mappings, provisionnez d'abord les groupes :
Sélectionnez Provision Microsoft Entra ID Groups.
Sur la page Attribute Mapping, désactivez le bouton Activé.
Le provisionnement de groupes SCIM n'est pas pris en charge dans GitLab. Laisser le provisionnement de groupe activé ne perturbe pas le provisionnement des utilisateurs SCIM, mais provoque des erreurs dans le journal de provisionnement SCIM d'Entra ID qui peuvent être déroutantes et trompeuses.
[!note] Même lorsque Provision Microsoft Entra ID Groups est désactivé, la section des mappings peut afficher Activé : Oui. Ce comportement est un bug d'affichage que vous pouvez ignorer en toute sécurité.
Sélectionnez Enregistrer.
Ensuite, provisionnez les utilisateurs :
externalId et supprimez-le.objectId.externalId.1.id est le champ principal et obligatoire, et que externalId est également obligatoire.X dans le coin supérieur droit.[!note] Pendant que Microsoft effectue la transition d'Azure Active Directory vers les schémas de nommage d'Entra ID, vous pourriez remarquer des incohérences dans votre interface utilisateur. Si vous rencontrez des difficultés, vous pouvez consulter une version plus ancienne de ce document ou contacter le support GitLab.
Lors de la configuration d'Entra ID pour SCIM, vous configurez les mappings d'attributs. Pour un exemple, consultez la configuration exemple.
Le tableau suivant fournit les mappings d'attributs requis pour GitLab.
| Attribut source | Attribut cible | Priorité de correspondance |
|---|---|---|
objectId | externalId | 1 |
userPrincipalName OU mail <sup>1</sup> | emails[type eq "work"].value | |
mailNickname | userName | |
displayName OU Join(" ", [givenName], [surname]) <sup>2</sup> | name.formatted | |
Switch([IsSoftDeleted], , "False", "True", "True", "False") <sup>3</sup> | active |
Footnotes :
mail comme attribut source lorsque userPrincipalName n'est pas une adresse e-mail ou n'est pas délivrable.Join si votre displayName ne correspond pas au format Firstname Lastname.Chaque mapping d'attribut possède :
Pour chaque attribut :
Si votre configuration SAML diffère des paramètres SAML recommandés, sélectionnez les attributs de mapping et modifiez-les en conséquence. L'attribut source que vous mappez à l'attribut cible externalId doit correspondre à l'attribut utilisé pour le SAML NameID.
Si un mapping n'est pas répertorié dans le tableau, utilisez les valeurs par défaut de Microsoft Entra ID. Pour obtenir la liste des attributs requis, consultez la documentation de l'API SCIM d'instance interne.
Sous la section Paramètres :
Après avoir configuré les mappings et les paramètres, revenez à la page de présentation de l'application et sélectionnez Start provisioning pour démarrer le provisionnement SCIM automatique des utilisateurs dans GitLab.
[!warning] Une fois synchronisé, la modification du champ mappé sur
idetexternalIdpeut provoquer des erreurs. Cela inclut des erreurs de provisionnement, des utilisateurs en double, et peut empêcher les utilisateurs existants d'accéder au groupe GitLab.
La suppression ou la désactivation d'un utilisateur sur le fournisseur d'identité bloque l'utilisateur sur l'instance GitLab, tandis que l'identité SCIM reste liée à l'utilisateur GitLab.
Pour mettre à jour l'identité SCIM de l'utilisateur, utilisez l'API SCIM GitLab interne.
{{< history >}}
skip_saml_identity_destroy_during_scim_deprovision. Désactivé par défaut.skip_saml_identity_destroy_during_scim_deprovision supprimé.{{< /history >}}
Après la suppression ou la désactivation d'un utilisateur via SCIM, vous pouvez réactiver cet utilisateur en l'ajoutant au fournisseur d'identité SCIM.
Après que le fournisseur d'identité effectue une synchronisation selon son calendrier configuré, l'identité SCIM de l'utilisateur est réactivée et son accès à l'instance GitLab est rétabli.
{{< history >}}
self_managed_scim_group_sync. Désactivé par défaut.self_managed_scim_group_sync supprimé.{{< /history >}}
En plus du provisionnement des utilisateurs, vous pouvez utiliser SCIM pour synchroniser les appartenances aux groupes entre votre fournisseur d'identité et GitLab. Avec cette méthode, vous pouvez ajouter et supprimer automatiquement des utilisateurs des groupes GitLab en fonction de leurs appartenances aux groupes dans votre fournisseur d'identité.
Prérequis :
La synchronisation des groupes SCIM fonctionne avec les liens de groupe SAML pour gérer les appartenances aux groupes. Lorsque votre fournisseur d'identité envoie des modifications d'appartenance aux groupes via l'API SCIM, GitLab met à jour les appartenances des utilisateurs dans tous les groupes GitLab qui ont des liens de groupe SAML associés à ce groupe SCIM.
SCIM est un protocole unidirectionnel : les modifications transitent de votre fournisseur d'identité vers GitLab. Si vous apportez des modifications aux liens de groupe SAML dans GitLab (par exemple en les ajoutant ou en les supprimant), votre fournisseur d'identité n'a aucun moyen de détecter ces modifications via SCIM.
Lorsque votre fournisseur d'identité provisionne un groupe SCIM pour la première fois (via POST /Groups), GitLab associe l'ID du groupe SCIM à tous les liens de groupe SAML existants qui ont un nom de groupe correspondant. Cependant, si vous ajoutez de nouveaux liens de groupe SAML avec le même nom de groupe après le provisionnement initial, les nouveaux liens de groupe ne sont pas automatiquement associés à l'ID du groupe SCIM. Cela signifie que les mises à jour d'appartenance SCIM de votre fournisseur d'identité n'affectent pas les utilisateurs dans les liens de groupe nouvellement ajoutés.
La prise en charge des améliorations est proposée dans l'issue 582729.
[!note] Pour vous assurer que tous les liens de groupe sont associés au groupe SCIM dès le départ, vous devez configurer tous les liens de groupe SAML avant de configurer le provisionnement de groupe SCIM dans votre fournisseur d'identité.
Si vous devez ajouter des liens de groupe après le provisionnement initial, vous pouvez re-provisionner le groupe SCIM dans votre fournisseur d'identité en supprimant le provisionnement du groupe SCIM (et non le groupe IdP lui-même), puis en le recréant. Cette action ré-associe tous les liens de groupe SAML actuels au groupe SCIM. Pour plus d'informations, consultez la documentation de votre fournisseur d'identité pour la gestion du provisionnement de groupe SCIM.
Si vous supprimez un lien de groupe SAML dans GitLab, les membres de ce groupe via ce lien restent dans le groupe. Cependant, SCIM ne gère plus leur appartenance à ce groupe car le lien de groupe a été supprimé. Si nécessaire, vous pouvez manuellement supprimer des membres du groupe.
Pour des instructions détaillées sur la configuration de la synchronisation des groupes dans votre fournisseur d'identité, consultez la documentation du fournisseur. Exemples ci-dessous :
displayName est utilisé pour trouver les liens de groupe SAML avec des noms conviviaux. - Cependant, si vos liens de groupe SAML utilisent un ID d'objet comme nom, vous devez mettre à jour l'attribut source vers objectId.[!warning] Lorsque plusieurs liens de groupe SAML correspondent au même groupe GitLab, les utilisateurs se voient attribuer le rôle le plus élevé parmi tous les liens de groupe de mapping. Les utilisateurs retirés d'un groupe IdP restent dans un groupe GitLab s'ils appartiennent à un autre groupe SAML qui y est lié.
L'application SCIM GitLab standard du catalogue d'applications Okta ne prend pas en charge la synchronisation des groupes. Vous pouvez également créer une intégration SCIM personnalisée pour la synchronisation des groupes avec Okta. Pour plus d'informations, consultez l'issue 582729.
Consultez notre guide de dépannage SCIM.