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 introduit 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 dans lequel un groupe SCIM était associé à une équipe Miro. Nous vous recommandons de migrer vers la synchronisation SCIM fondé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 restreint à 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 via @mention dans les commentaires pour notifier tous ses membres, et gérer les groupes de façon programmatique via l’API User Groups, de sorte que le provisionnement depuis 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 la composition du groupe d’utilisateurs Miro.
Important :
- L’authentification unique (SSO) basée sur SAML doit être correctement configurée et fonctionnelle 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é (IdP) avec les groupes d’utilisateurs Miro est facultative. Vous pouvez choisir de lier et de 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 la composition de ce groupe d’utilisateurs. Vous pouvez aussi créer et gérer des groupes d’utilisateurs directement à l’aide de l’API des groupes d’utilisateurs. Contrairement aux équipes, un groupe d’utilisateurs n’est pas limité à une seule équipe, vous pouvez donc synchroniser des structures organisationnelles couvrant plusieurs équipes. Pour en savoir plus sur la manière dont l’API SCIM vous permet de gérer les groupes, consultez la documentation pour développeurs de Miro.
-
Les modifications d’adresse e-mail via SCIM comprennent les 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 qui initie la requête SCIM, la mise à jour de l’adresse e-mail est bloquée et renvoie une erreur 400.
- Vérification du domaine e-mail cible : Si le domaine e-mail cible est revendiqué par une organisation autre que celle qui initie la requête SCIM, la mise à jour de l’adresse e-mail est bloquée et renvoie une erreur 400. Si le domaine e-mail cible est revendiqué par l’organisation qui initie la requête SCIM, la mise à jour est autorisée sans confirmation par e-mail. Les journaux d’audit enregistrent la mise à jour dans chaque organisation dont l’utilisateur est membre.
- Contrôle de domaine et SSO : Les mises à jour de l’e-mail sont autorisées en fonction de la vérification du domaine via le Contrôle de domaine (IDC) ou l’authentification unique (SSO). Si le domaine e-mail cible est vérifié via CD ou SSO par l’organisation initiatrice, 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 modifications d’appartenance sont appliquées directement et immédiatement : une opération d’ajout, de suppression ou de remplacement sur les membres d’un groupe SCIM ajoute ou supprime ce membre du groupe d’utilisateurs Miro correspondant, sans étape distincte de "push". Par exemple : a) si un utilisateur est membre du groupe d’utilisateurs A du côté de 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 n’est pas modifiée — il devient simplement aussi membre du groupe d’utilisateurs B. 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 la licence gratuite restreinte. b) Pour les abonnements Enterprise avec le programme de licences flexibles activé : une licence Free ou une 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 à l’aide de l’attribut UserTypeattribut avec une valeur Collaborate ou complète (héritée). Les utilisateurs mis à jour via cet attribut verront leur licence passer à Collaborate ou à la licence complète (héritée) sans interruption pour eux. Remarque : l’ajout d’un membre à un groupe d’utilisateurs via SCIM réactive ou recrée ce membre s’il avait été précédemment désactivé ou supprimé, et met à niveau sa licence vers Collaborate ou la licence complète (héritée). - 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, cet 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 limite GET scim/users
GET scim/users/{userId}Premier niveau de limitation 1 POST scim/users/{userId}
PUT scim/users/{userId}
PATCH scim/users/{userId}
DELETE scim/users/{userId}Troisième niveau de limitation 3 GET scim/Groups
PATCH scim/Groups/{groupId}Quatrième niveau de limitation 4 GET scim/Groups/{groupId} Troisième niveau de limitation 4 Pour plus de détails sur les niveaux de limite, consultez ici. Si le nombre de requêtes dépasse la limite, Miro renverra le message standard 429 Too many requests.
Fonctionnalités prises en charge
Le schéma SCIM détaillé de Miro se trouve ici. Des informations détaillées sur les endpoints Groups (groupes d’utilisateurs) sont disponibles 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 attribués à l’application Miro dans l’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 connaître les attributs et les modifications pris en charge, voir ci-dessous.
-
Synchroniser les groupes IdP avec les groupes d’utilisateurs
Synchronisez vos groupes IdP avec les groupes d’utilisateurs de votre abonnement Miro Enterprise pour gérer automatiquement l’appartenance. Comme un groupe SCIM correspond directement à un groupe d’utilisateurs Miro, les opérations d’ajout et de suppression effectuées dans votre IdP s’appliquent immédiatement à l’appartenance du groupe d’utilisateurs — il n’y a pas d’étape distincte de push ou d’écrasement nécessaire.
-
Retirer des utilisateurs d’un groupe du fournisseur d’identité (IdP)/d’un groupe d’utilisateurs Miro (pas de l’abonnement Enterprise, voir ci‑dessous) Le retrait d’un utilisateur d’un groupe du fournisseur d’identité (IdP) le retire immédiatement du groupe d’utilisateurs Miro correspondant. Cela ne retire l’utilisateur que du groupe d’utilisateurs. Cela ne le retire pas d’une équipe ni de l’organisation, ne transfère pas la propriété du tableau et ne modifie pas sa licence. Il n’existe aucune restriction du dernier admin pour les groupes d’utilisateurs, et le fait de retirer un utilisateur qui n’est pas déjà membre n’a aucun effet.
-
Désactiver les utilisateurs
Désactiver/supprimer un utilisateur ou désactiver l’accès d’un utilisateur à l’application dans le fournisseur d’identité (IdP) désactivera cet utilisateur dans votre forfait Miro Enterprise. L’utilisateur passe d’un état Actif à un état Désactivé (et change de section dans la liste des utilisateurs) et ne consomme plus de licence. La désactivation seule ne modifie pas les appartenances de l’utilisateur aux groupes d’utilisateurs, ni ne réaffecte la propriété des tableaux.
Supprimer un utilisateur de l’abonnement Enterprise n’est pas pris 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 mettre à l’état 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, la réattribution du contenu.
-
Rétrograder des utilisateurs
Vous ne pouvez rétrograder des utilisateurs qu’entre des licences payantes. Par exemple, vous pouvez rétrograder un utilisateur d’un userType Accelerate vers un userType Collaborate.
-
Réactiver les utilisateurs
Réaffecter un utilisateur à l’application ou réactiver son profil chez 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’attribution des groupes de facturation
Affecter 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 classé dans la bonne catégorie de facturation.
-
Partager des tableaux et des espaces avec un groupe Un groupe d’utilisateurs Miro s’intègre au même modèle d’autorisations utilisé dans l’ensemble de Miro, vous pouvez donc 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 un par un.
-
@mentioner un groupe dans les commentaires Mentionnez un groupe d’utilisateurs dans les commentaires d’un tableau pour notifier tous ses membres en une seule fois.
- Gérer les groupes de manière programmatique Créez, mettez à jour et supprimez directement des groupes d’utilisateurs à l’aide de l’API des groupes d’utilisateurs, indépendamment de la synchronisation avec votre fournisseur d’identité (IdP).
Vous pouvez également supprimer des utilisateurs de votre forfait Enterprise en envoyant un appel API direct de suppression - veuillez consulter 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 être au format 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é (IdP) et celle de Miro sont identiques, sinon Miro ne reconnaîtra pas l’utilisateur et un profil Miro dupliqué sera créé pour la nouvelle adresse e-mail. La mise à jour de l’e-mail doit être effectuée dans le profil IdP 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éclenche une notification : l’ancienne et la nouvelle adresse e-mail recevront chacune 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 nécessaires mais 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" Remarque : Standard et Advanced sont des types d’utilisateur hérités. |
| Actif | 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 responsable | manager.displayName |
| Identifiant du responsable | manager.value — "value" a le type String dans la norme SCIM mais le champ interne managerId a le type Long ; les valeurs non numériques sont ignorées. |
⚠️ Les changements de mot de passe ne sont pas pris en charge et il n’est pas prévu de le faire dans l’immédiat. ⚠️ Username, UserType et roles.value ne peuvent pas être mis à jour pour les utilisateurs désactivés.
Tous les attributs s’afficheront dans le fichier CSV exporté contenant la liste des utilisateurs, qui peut être téléchargé 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, activez la fonctionnalité SCIM Provisioning. 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 le configurer dans votre fournisseur d’identité.
Problèmes éventuels et comment les résoudre
1. Les utilisateurs ne sont pas approvisionnés en raison d’une erreur liée à la liste d’autorisations.
Assurez-vous que l’adresse de domaine de l’utilisateur est ajoutée à votre liste d’autorisations dans les paramètres de sécurité.
2. Si vous authentifiez vos utilisateurs finaux à l’aide d’une solution d’identité (IdP1) mais souhaitez activer le SCIM via une solution différente (IdP2), cela est possible sous deux conditions :
- l’IdP2 peut effectuer des appels d’API avec le jeton Bearer.
- les deux fournisseurs d’identité sont synchronisés (c’est-à-dire que les utilisateurs approvisionnés par SCIM existent également dans l’IdP1 et peuvent donc s’authentifier auprès de 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.