Le système de gestion inter-domaines (SCIM) vous permet d’automatiser le provisionnement et la gestion des utilisateurs entre Miro et votre fournisseur d’identité (IdP).
Disponible pour : le forfait Enterprise
Configuré par : les admins d’entreprise
Nouveau modèle de synchronisation
Miro met en place un nouveau modèle de synchronisation SCIM dans lequel un groupe SCIM correspond désormais à un groupe d’utilisateurs Miro, remplaçant l’ancien modèle où un groupe SCIM était associé à une équipe Miro. Nous recommandons de migrer vers la synchronisation SCIM basée sur les groupes d’utilisateurs dès que possible.
Contrairement aux équipes, les groupes d’utilisateurs ne sont pas limités à une seule équipe, ce qui vous permet de synchroniser des structures organisationnelles couvrant plusieurs équipes au lieu d’être limité à une correspondance 1:1 avec une équipe. Les groupes d’utilisateurs s’intègrent également directement au même modèle d’autorisations utilisé dans tout Miro. Vous pouvez partager des tableaux et des espaces avec un groupe, @mentionner un groupe dans les commentaires pour notifier tous ses membres, et gérer les groupes de façon programmatique via l’API des groupes d’utilisateurs, de sorte que le provisionnement via votre fournisseur d’identité reste désormais synchronisé avec le fonctionnement existant du partage et des accès dans Miro.
Remarque : Il s’agit de la version la plus récente de l’API dans laquelle un groupe SCIM correspond à un groupe d’utilisateurs Miro. L’ajout ou la suppression de membres d’un groupe SCIM modifie l’appartenance au groupe d’utilisateurs Miro.
Important :
- Le SSO basé sur SAML doit être correctement configuré et fonctionnel dans votre forfait Enterprise avant de commencer à configurer le provisionnement automatisé. Voir le guide de configuration de SAML SSO.
- La synchronisation des groupes du fournisseur d’identité avec les groupes d’utilisateurs Miro est facultative. Vous pouvez, si vous le souhaitez, lier et synchroniser vos groupes du fournisseur d’identité avec des groupes d’utilisateurs dans Miro. Un groupe SCIM correspond directement à un groupe d’utilisateurs Miro — la création, la mise à jour ou la suppression d’un groupe SCIM entraîne la création, la mise à jour ou la suppression du groupe d’utilisateurs correspondant, et l’ajout ou la suppression de membres modifie l’appartenance à ce groupe d’utilisateurs. Vous pouvez aussi créer et gérer des groupes d’utilisateurs directement via l’API des groupes d’utilisateurs. Contrairement aux équipes, un groupe d’utilisateurs n’est pas limité à une seule équipe, ce qui vous permet de synchroniser des structures organisationnelles s’étendant sur plusieurs équipes. Pour en savoir plus sur la façon dont l’API SCIM vous permet de gérer les groupes, consultez la documentation développeur Miro.
-
Les modifications d’adresse e-mail dans SCIM sont soumises aux règles de validation suivantes :
- Vérification de l’utilisateur géré : Si le domaine actuel de l’utilisateur n’est pas revendiqué par l’organisation à l’origine de la requête SCIM, la mise à jour du e-mail est bloquée et renvoie une erreur 400.
- Vérification du domaine de destination du e-mail : Si le domaine de destination du e-mail est revendiqué par une organisation autre que celle à l’origine de la requête SCIM, la mise à jour du e-mail est bloquée et renvoie une erreur 400. Si le domaine de destination du e-mail est revendiqué par l’organisation à l’origine de la requête SCIM, la mise à jour est autorisée sans exiger de confirmation par e-mail. Les journaux d’audit enregistrent la mise à jour dans chaque organisation où l’utilisateur est membre.
- Contrôle de domaine et SSO : Les mises à jour du e-mail sont autorisées si le domaine est vérifié via le contrôle de domaine (IDC) ou via l’authentification unique (SSO). Si le domaine de destination du e-mail est vérifié via CD ou SSO par l’organisation à l’origine de la requête, la mise à jour peut être effectuée.
Un diagramme du workflow de validation du changement d’e-mail SCIM
Les règles sur lesquelles se fonde le SCIM de Miro
- Les modifications synchronisées par SCIM sont principalement appliquées aux utilisateurs nouvellement affectés. Les changements d’appartenance sont appliqués directement et immédiatement : une opération d’ajout, de suppression ou de remplacement sur les membres d’un groupe SCIM ajoute ou retire ce membre du groupe d’utilisateurs Miro correspondant, sans étape "push" séparée requise. Par exemple : a) si un utilisateur est membre du groupe d’utilisateurs A côté Miro et que votre fournisseur d’identité envoie une mise à jour pour l’ajouter au groupe d’utilisateurs B, son appartenance au groupe d’utilisateurs A reste inchangée — il devient simplement membre du groupe d’utilisateurs B également. b) si votre fournisseur d’identité envoie une mise à jour contenant des modifications concernant User1, les autres membres du groupe d’utilisateurs ne sont pas affectés.
- Tous les utilisateurs provisionnés sous SCIM se voient attribuer la licence par défaut de votre abonnement : a) Pour les abonnements Enterprise sans programme de licences flexibles : une licence Collaborate ou Full (legacy). Si votre abonnement n’a plus de licences, les utilisateurs commencent à être provisionnés sous licence gratuite restreinte. b) Pour les abonnements Enterprise avec le programme de licences flexibles activé : Free ou licence gratuite restreinte en fonction de la licence d’abonnement par défaut.
Si vous avez besoin que certains utilisateurs soient provisionnés sous une licence différente de celle par défaut : comme indiqué ci‑dessus, tous les utilisateurs sont provisionnés avec la licence par défaut. Toutefois, vous pouvez immédiatement mettre à jour tout ou partie d’entre eux en utilisant l’attribut UserType avec la valeur Collaborate ou Full (legacy). Les utilisateurs mis à jour à l’aide de cet attribut seront passés à la licence Collaborate ou Full (legacy) sans interruption pour l’utilisateur. Remarque : l’ajout d’un membre à un groupe d’utilisateurs via SCIM réactive ou recrée également ce membre s’il avait été précédemment désactivé ou supprimé, et lui attribue la licence Collaborate ou Full (legacy). - Tous les utilisateurs provisionnés via SCIM sont également concernés par la fonctionnalité contrôle de domaine. Cela signifie que si un utilisateur n’est membre que d’un seul groupe de sécurité dans votre fournisseur d’identité, mais que vos paramètres de contrôle de domaine désignent trois équipes, l’utilisateur sera également ajouté à ces trois équipes.
-
Pour protéger le service, Miro limite le nombre d’appels API disponibles toutes les 30 secondes :
Type de demande Niveau de limitation GET scim/users
GET scim/users/{userId}Premier niveau de limitation (niveau 1) POST scim/users/{userId}
PUT scim/users/{userId}
PATCH scim/users/{userId}
DELETE scim/users/{userId}Troisième niveau de limitation (niveau 3) GET scim/Groups
PATCH scim/Groups/{groupId}Quatrième niveau de limitation (niveau 4) GET scim/Groups/{groupId} Troisième niveau de limitation (niveau 4) Pour plus de détails sur les niveaux de limitation, consultez ici. Si le nombre de requêtes dépasse la limite, Miro renverra le message standard 429 Trop de requêtes.
Fonctionnalités prises en charge
Le schéma détaillé du SCIM de Miro se trouve ici. Les informations détaillées sur les endpoints Groups (groupes d’utilisateurs) se trouvent dans la documentation de l’API Groups.
Miro prend en charge les fonctionnalités de provisionnement suivantes :
-
Créer de nouveaux utilisateurs
Les nouveaux utilisateurs affectés à l’application Miro dans le fournisseur d’identité (IdP) seront créés dans votre abonnement Miro Enterprise en tant que membres Enterprise. Les utilisateurs ajoutés à un groupe IdP synchronisé avec un groupe d’utilisateurs Miro seront ajoutés directement à ce groupe d’utilisateurs en tant que membres.
-
Push des mises à jour des profils d’utilisateurs
Pour les attributs et les modifications pris en charge, voir ci-dessous.
-
Synchroniser les groupes du fournisseur d’identité (IdP) avec des groupes d’utilisateurs
Synchronisez les groupes de votre fournisseur d’identité (IdP) avec les groupes d’utilisateurs de votre abonnement Miro Enterprise pour gérer automatiquement les adhésions. Comme un groupe SCIM correspond directement à un groupe d’utilisateurs Miro, les opérations d’ajout et de suppression depuis votre fournisseur d’identité s’appliquent immédiatement aux membres du groupe d’utilisateurs — il n’y a pas d’étape distincte de push ou d’écrasement nécessaire.
-
Supprimer des utilisateurs d’un groupe IdP/groupe d’utilisateurs Miro (pas de l’abonnement Enterprise, voir ci‑dessous) Le retrait d’un utilisateur d’un groupe du fournisseur d’identité le supprime immédiatement du groupe d’utilisateurs Miro correspondant. Cela le retire uniquement du groupe d’utilisateurs. Cela ne le retire pas d’une équipe ni de l’organisation, ne transfère pas la propriété des tableaux et ne modifie pas sa licence. Il n’existe aucune restriction du dernier admin pour les groupes d’utilisateurs, et le retrait d’un utilisateur qui n’en est pas déjà membre n’a aucun effet.
-
Désactiver des utilisateurs
La désactivation ou la suppression d’un utilisateur, ou la désactivation de l’accès d’un utilisateur à l’application dans le fournisseur d’identité, désactivera l’utilisateur dans votre plan Miro Enterprise. L’utilisateur passe d’un Actif à un Désactivé (et dans la section des utilisateurs correspondante) et ne consomme plus de licence. La désactivation seule ne modifie pas les appartenances aux groupes d’utilisateurs ni ne réaffecte la propriété des tableaux.
La suppression d’un utilisateur de l’abonnement Enterprise n’est pas prise en charge par défaut. Vous pouvez néanmoins ajouter manuellement la fonctionnalité à l’aide de l’API pour supprimer complètement l’utilisateur de l’abonnement au lieu de le passer au statut Désactivé état. Dans ce scénario, le contenu est réattribué aux membres respectifs de l’équipe. Il est impossible de définir quels admins deviendront propriétaires du contenu réattribué automatiquement, mais cela peut être défini lorsque vous désactivez manuellement un utilisateur dans les paramètres Miro. La suppression d’un utilisateur d’un groupe d’utilisateurs (voir ci‑dessus) ne déclenche jamais à elle seule une réattribution du contenu.
-
Rétrograder les utilisateurs
Vous pouvez uniquement rétrograder des utilisateurs entre des licences payantes. Par exemple, vous pouvez rétrograder un utilisateur d’un userType Accelerate à un userType Collaborate.
-
Réactiver les utilisateurs
Réassigner un utilisateur à l’application ou réactiver le profil de l’utilisateur dans le fournisseur d’identité (IdP) le réactivera dans votre abonnement Miro Enterprise s’il avait été précédemment provisionné et désactivé.
-
Automatisation de l’affectation aux groupes de facturation
Affectez automatiquement les nouveaux utilisateurs aux groupes de facturation à l’aide du SCIM. Une fois votre fournisseur d’identité (IdP) configuré, associez vos centres de coûts à vos groupes de facturation. Ainsi, chaque utilisateur actuel et futur de ces centres de coûts est automatiquement affecté à la bonne catégorie de facturation.
-
Partager des tableaux et des espaces avec un groupe Parce qu’un groupe d’utilisateurs Miro s’intègre au même modèle d’autorisations utilisé dans Miro, vous pouvez partager des tableaux et des espaces directement avec un groupe d’utilisateurs synchronisé depuis votre fournisseur d’identité (IdP), au lieu d’ajouter les membres individuellement.
-
@mentionner un groupe dans les commentaires Utilisez @mention sur un groupe d’utilisateurs dans les commentaires du tableau pour notifier tous ses membres en une seule fois.
- Gérer les groupes par programmation Créez, mettez à jour et supprimez des groupes d’utilisateurs directement à l’aide de l’API des groupes d’utilisateurs, indépendamment de la synchronisation avec votre fournisseur d’identité.
Vous pouvez également supprimer des utilisateurs de votre forfait Enterprise en envoyant directement un appel API Suppression — consultez la documentation ici. Notez que seuls les appels directs supprimeront les utilisateurs. Les événements de Suppression initiés par votre solution d’identité seront traités comme une demande de Désactivation.
Attributs pris en charge
Remarque : L’e-mail (le paramètre principal / identifiant unique / nom d’utilisateur) est la seule valeur requise par Miro et doit se présenter sous la forme d’une adresse e-mail. La mise à jour de l’e-mail n’est possible que pour les utilisateurs déjà synchronisés — la première synchronisation doit avoir lieu lorsque l’adresse e-mail dans le fournisseur d’identité et Miro est la même, sinon Miro ne reconnaîtra pas l’utilisateur et un profil Miro en double sera créé sous la nouvelle adresse e-mail. La mise à jour de l’adresse e-mail doit se faire dans le profil du fournisseur d’identité de l’utilisateur, et non dans la liste des affectations. Contrairement aux autres attributs, la mise à jour de l’e-mail de l’utilisateur déclenchera une notification : l’ancienne et la nouvelle adresse e-mail recevront toutes deux un message informant l’utilisateur qu’il doit désormais utiliser sa nouvelle adresse e-mail pour se connecter à Miro.
| Nom de l’attribut | Attribut SCIM (Claim) |
|---|---|
| Nom d’utilisateur. Doit être présent et sous la forme d’une adresse e-mail | |
| Les attributs énumérés ci-dessous ne sont pas requis et seront acceptés par Miro s’ils sont présents (les autres attributs envoyés à Miro seront ignorés). | |
| Nom complet | displayName; formatted; givenName + " " + familyName; userName |
| Type d’utilisateur | userType — valeurs prises en charge : "Full", "Standard", "Collaborate", "Accelerate", "Advanced" Note : Standard et Advanced sont tous deux des types d’utilisateur hérités. |
| Active | active — valeur prise en charge : "true" ou "false" |
| Photo de profil | photos.^[type==’photo’].value ou photos.^[type==photo].value (Okta); photos[type eq "photo"].value (Entra). Doit être une URL textuelle vers l’image. Types de fichiers pris en charge : jpg, jpeg, bmp, png, gif. Taille maximale du fichier à télécharger : 31 457 280 bytes. |
| Rôle utilisateur | roles.^[primary==true].value (Okta); roles[primary eq "True"].value (Entra) — valeurs prises en charge : ORGANIZATION_INTERNAL_ADMIN, ORGANIZATION_INTERNAL_USER |
| Numéro d’employé | employeeNumber |
| Centre de coûts | costCenter |
| Organisation | organization |
| Division | division |
| Département | department |
| Nom du manager | manager.displayName |
| Identifiant du manager | manager.value — "value" a le type String dans la norme SCIM mais le champ interne managerId est de type Long ; les valeurs non numériques sont ignorées. |
⚠️ Les comptes Miro n’ont pas de mot de passe — la connexion se fait via lien magique, SSO ou un compte social — il n’existe donc pas d’attribut mot de passe à synchroniser via SCIM. ⚠️ Username, UserType et roles.value ne peuvent pas être mis à jour pour les utilisateurs désactivés.
Tous les attributs seront affichés dans le fichier CSV exporté contenant la liste des utilisateurs, téléchargeable depuis la section Utilisateurs actifs.
Configuration du SCIM
Étape 1 : activer l’option SCIM dans Miro
Pour activer le SCIM pour votre forfait Miro Enterprise, rendez-vous dans les paramètres de l’entreprise > Intégrations Enterprise, puis activez la fonctionnalité de provisionnement SCIM. Vous y trouverez l’URL de base et le jeton API pour configurer votre fournisseur d’identité.
Étape 2 : configurer votre fournisseur d’identité
La configuration dépendra du fournisseur d’identité que vous utilisez. Miro prend en charge Okta et Entra ID préconfigurés, mais vous pouvez utiliser n’importe quel fournisseur d’identité tant qu’il permet de configurer le SCIM.
OKTA : consultez les instructions de configuration ici.
Entra ID : consultez les instructions de configuration ici.
Générer un nouveau jeton
- Allez dans les paramètres de l’entreprise > Intégrations Enterprise.
- Dans la section SCIM Provisioning, cliquez sur Générer un nouveau jeton.
- Dans la fenêtre Générer un nouveau jeton SCIM, cliquez sur Générer.
- Après avoir généré un nouveau jeton, vous devez configurer le nouveau jeton dans votre fournisseur d’identité.
Problèmes éventuels et comment les résoudre
Assurez-vous que l’adresse du domaine de l’utilisateur est ajoutée à votre liste d’autorisations dans les paramètres de sécurité.
- l’IdP2 peut faire des appels d’API avec le jeton titulaire.
- les deux fournisseurs d’identité sont synchronisés (c’est-à-dire que les utilisateurs approvisionnés par le SCIM existent dans l’IdP1 également et peuvent donc s’authentifier avec Miro).
Pour plus d’informations sur les erreurs SCIM, consultez notre documentation. Si le problème persiste, vous pouvez contacter le service d’assistance Miro.