Configurer le mappage de groupes SAML Apidog avec Microsoft Entra ID
Le mappage de groupes SAML attribue l’accès aux équipes Apidog à partir des groupes présents dans l’assertion SAML d’un utilisateur. Il réduit la gestion manuelle des membres tout en conservant Microsoft Entra ID comme source de vérité.
Essayez Apidog dès aujourd’hui
Ce tutoriel explique comment ajouter une revendication groups, mapper un groupe Entra à une équipe Apidog et vérifier les permissions initiales du projet.
Avant de commencer
Vous aurez besoin de :
- une organisation Apidog Enterprise avec le SSO SAML déjà configuré ;
- un accès Propriétaire ou Administrateur de l’organisation dans Apidog ;
- un accès administrateur à l’application d’entreprise Microsoft Entra utilisée pour Apidog ;
- au moins un groupe Entra et un utilisateur de test affecté à ce groupe.
Si SAML n’est pas encore configuré, suivez d’abord Configurer Microsoft Entra ID.
Le mappage de groupes SAML contrôle l’accès aux équipes et aux projets Apidog. Il n’accorde pas l’accès aux API de production et ne remplace pas l’autorisation d’exécution.
Comment l’accès initial au projet est attribué
Lorsqu’un groupe correspond, Apidog ajoute l’utilisateur à l’équipe mappée et déduit son accès initial au projet du rôle d’équipe sélectionné.
| Rôle d’équipe mappé | Rôle de projet initial |
|---|---|
| Administrateur d’équipe | Mainteneur de projet |
| Membre d’équipe | Lecture seule du projet |
| Invité d’équipe | Lecture seule du projet |
Apidog crée les appartenances de projet manquantes ou met à jour celles qui n’ont pas encore de rôle. Un rôle de projet déjà attribué manuellement n’est pas écrasé lors des connexions SAML suivantes.
Étape 1 : ajouter la revendication groups dans Microsoft Entra ID
- Connectez-vous au centre d’administration Microsoft Entra.
- Ouvrez Applications d’entreprise, puis l’application utilisée pour le SSO Apidog.
- Sélectionnez Authentification unique, puis Attributs & Revendications.
- Cliquez sur Ajouter une revendication de groupe.
- Choisissez Tous les groupes.
- Activez Personnaliser le nom de la revendication de groupe et saisissez
groups. - Enregistrez la revendication.
Configurez la revendication afin qu’Apidog reçoive les ID d’objet des groupes Entra dans l’attribut groups.
Apidog utilise les ID d’objet présents dans cette revendication. Il ne récupère pas d’autres informations sur les groupes depuis Microsoft Entra ID.
Étape 2 : copier le nom du groupe Entra et son ID d’objet
- Dans Microsoft Entra ID, ouvrez Groupes.
- Sélectionnez le groupe auquel vous souhaitez donner accès dans Apidog.
- Copiez son Nom et son ID d’objet.
Utilisez l’ID d’objet affiché sur la page du groupe. Ne le remplacez pas par un ID d’application, un ID de locataire ou un nom d’affichage.
Conservez cette page ouverte pendant la configuration dans Apidog.
Étape 3 : mapper le groupe à une équipe Apidog
- Ouvrez l’organisation dans Apidog.
- Accédez aux paramètres Groupe SAML.
- Ajoutez un mappage de groupe.
- Saisissez le nom du groupe Entra et collez son ID d’objet.
- Sélectionnez les équipes Apidog auxquelles le groupe doit accéder.
- Choisissez le rôle d’équipe requis pour chaque équipe.
- Enregistrez le mappage.
Associez l’ID d’objet Entra aux équipes Apidog et aux rôles d’équipe requis.
Le mappage de groupes SAML ne propose pas de rôle de projet distinct. Le rôle initial est déduit du rôle d’équipe indiqué dans le tableau précédent.
Pour accorder un accès différent, modifiez ensuite le rôle de l’utilisateur depuis les paramètres des membres du projet.
Étape 4 : tester le mappage
Utilisez un compte de test plutôt qu’un compte administrateur.
- Vérifiez que l’utilisateur de test appartient au groupe Entra mappé.
- Déconnectez-vous d’Apidog.
- Reconnectez-vous via le point d’entrée SSO de l’organisation.
- Ouvrez l’équipe mappée et vérifiez qu’elle est disponible.
- Vérifiez le rôle d’équipe de l’utilisateur.
- Ouvrez les projets de l’équipe et confirmez le rôle de projet initial.
Si l’utilisateur possédait déjà un rôle de projet attribué manuellement, vérifiez qu’il reste inchangé après une nouvelle connexion SSO.
Vérifier la suppression d’une appartenance
Testez également la suppression de groupe avant le déploiement.
- Retirez l’utilisateur de test du groupe Entra mappé.
- Attendez que la modification soit propagée par le fournisseur d’identité.
- Demandez à l’utilisateur de se reconnecter via SSO.
- Vérifiez son appartenance à l’équipe et aux projets concernés.
Lorsqu’un utilisateur n’est plus inclus dans un groupe mappé, Apidog peut le supprimer de l’équipe correspondante lors de la synchronisation SAML. Si l’appartenance à l’équipe est supprimée, les appartenances aux projets de cette équipe le sont également.
N’utilisez pas de compte de production pour ce premier test. Documentez le résultat observé pour votre configuration d’identité et votre procédure de désactivation.
Dépannage
| Problème | Vérifications |
|---|---|
| L’utilisateur se connecte mais n’est pas ajouté à l’équipe | Vérifiez que la revendication s’appelle exactement groups, que l’assertion contient l’ID d’objet attendu et que l’ID enregistré dans Apidog ne contient pas d’espace supplémentaire. |
| L’assertion ne contient aucune valeur de groupe | Vérifiez l’appartenance de l’utilisateur au groupe et l’envoi des revendications de groupe par l’application d’entreprise Entra. Pour les utilisateurs appartenant à de nombreux groupes, consultez les directives Microsoft sur les dépassements de revendication. |
| L’utilisateur reçoit le mauvais rôle de projet | Vérifiez le rôle d’équipe mappé. Les rôles de projet existants ne sont pas écrasés par une synchronisation SAML ultérieure. |
| Une modification de groupe n’est pas reflétée | Vérifiez que la modification est bien enregistrée dans Entra, puis forcez une nouvelle connexion SSO afin qu’Apidog synchronise l’assertion actuelle. |
| L’utilisateur reste dans l’organisation | Le mappage SAML gère l’accès aux équipes mappées. L’appartenance à l’organisation peut aussi être gérée par les invitations, le SSO ou SCIM. |
Limitations importantes
- Apidog ne crée ni ne supprime les groupes du fournisseur d’identité via SCIM.
- Le mappage de groupes SAML ne permet pas de définir un rôle distinct pour chaque projet.
- Les rôles de projet déjà attribués ne sont pas réinitialisés lors des connexions SSO suivantes.
- Si plusieurs mappages peuvent s’appliquer au même utilisateur et à la même équipe, testez le résultat avant le déploiement au lieu de supposer une règle de précédence.
- Les rôles d’espace de travail n’autorisent pas les appels aux API déployées.
Tutoriels connexes sur la gouvernance des API
Ces tutoriels couvrent des contrôles complémentaires pour la gouvernance d’un espace de travail API d’entreprise :
- Cadre de gouvernance des API — relie propriété, contrôles, preuves et décisions liées au cycle de vie.
- Mappage de groupes SAML avec Microsoft Entra ID — attribue l’accès aux équipes à partir des groupes du fournisseur d’identité.
- Scanner de secrets — détecte les informations d’identification potentiellement exposées dans les ressources Apidog prises en charge.
- Journaux d’audit — permet d’enquêter sur l’activité administrative de l’organisation et de l’exporter.
- Provisionnement SCIM — gère le cycle de vie des utilisateurs de l’organisation.
- Politiques d’entreprise — configure les contrôles liés aux identifiants, aux appartenances, aux sessions SSO et aux invitations.
- Équipes API en libre-service — permet aux membres de créer des équipes tout en conservant une supervision de la propriété.
- Intégration GitHub Enterprise Cloud — connecte les dépôts GHE.com pris en charge pour les flux de travail OpenAPI.
Top comments (0)