Le système de gestion inter-domaines d’identités (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 où un groupe SCIM était associé à une équipe Miro. Nous recommandons de migrer dès que possible vers la synchronisation SCIM basée sur les groupes d’utilisateurs.
Contrairement aux équipes, les groupes d’utilisateurs ne sont pas confinés à une seule équipe, vous pouvez donc synchroniser des structures organisationnelles qui s’étendent sur plusieurs équipes au lieu d’être limités à une correspondance 1:1 par équipe. Les groupes d’utilisateurs s’intègrent également directement au même modèle d’autorisations utilisé dans 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 manière programmatique via l’API User Groups, de sorte que le provisionnement via votre fournisseur d’identité reste désormais synchronisé avec le fonctionnement 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 SCIM Group correspond à un groupe d’utilisateurs Miro. L’ajout ou la suppression de membres d’un SCIM Group 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 que vous ne commenciez à 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, si vous le souhaitez, lier et synchroniser vos groupes du fournisseur d’identité avec des groupes d’utilisateurs Miro. Un groupe SCIM correspond directement à un groupe d’utilisateurs Miro — la création, la mise à jour ou la suppression d’un groupe SCIM crée, met à jour ou supprime le 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 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 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 développeur Miro.
-
Les modifications d’adresse e-mail dans SCIM obéissent 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 de l’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 à l’origine de la requête SCIM, la mise à jour de l’e-mail est bloquée et renvoie une erreur 400. Si le domaine e-mail cible est revendiqué par l’organisation à l’origine de 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 authentification unique (SSO) : Les mises à jour d’adresse 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 le contrôle de domaine (IDC) ou l’authentification unique (SSO) par l’organisation initiatrice, la mise à jour peut être effectuée.
Schéma du workflow de validation du changement d’adresse e-mail SCIM
Les règles sur lesquelles se fonde le SCIM de Miro
- Les modifications synchronisées par le 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 qu’une étape distincte de "push" soit 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 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 complète. 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é : licence 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 attribut avec la valeur Full. Les utilisateurs mis à jour avec cet attribut verront leur licence passer à une licence complète sans interruption pour l’utilisateur. 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 lui attribue une licence complète. - Tous les utilisateurs provisionnés via SCIM sont également concernés par la fonctionnalité contrôle de domaine. Cela signifie que si un utilisateur est membre d’un seul groupe de sécurité chez votre fournisseur d’identité, mais que vos paramètres de contrôle de domaine définissent trois équipes comme désignées, 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 limite GET scim/users
GET scim/users/{userId}Niveau 1 de limitation POST scim/users/{userId}
PUT scim/users/{userId}
PATCH scim/users/{userId}
DELETE scim/users/{userId}Niveau 3 de limitation GET scim/Groups
PATCH scim/Groups/{groupId}Niveau 4 de limitation GET scim/Groups/{groupId} Troisième niveau de limitation 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 Too many requests.
Fonctionnalités prises en charge
Le schéma détaillé du SCIM de Miro se trouve ici. Des informations détaillées sur les points de terminaison 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 affectés à l’application Miro dans votre fournisseur d’identité (IdP) seront créés dans votre abonnement Miro Enterprise en tant que membres Enterprise. Les utilisateurs ajoutés à un groupe du fournisseur d’identité 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 modifications pris en charge, voir ci‑dessous.
-
Synchroniser les groupes du fournisseur d’identité (IdP) avec des groupes d’utilisateurs
Synchronisez vos groupes du 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 effectuées dans votre fournisseur d’identité s’appliquent immédiatement à l’appartenance au groupe d’utilisateurs — il n’y a pas d’étape distincte de push/surcharge à effectuer.
-
Retirer des utilisateurs d’un groupe du fournisseur d’identité/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 ne supprime l’utilisateur que du groupe d’utilisateurs. Cela ne le retire pas d’une quelconque équipe ni de l’organisation, ne transfère pas la propriété du tableau et ne modifie pas sa licence. Il n’y a pas de restriction du dernier admin pour les groupes d’utilisateurs, et retirer un utilisateur qui n’est pas déjà membre n’a aucun effet.
-
Désactiver les utilisateurs
La désactivation/la suppression d’un utilisateur ou la désactivation de l’accès d’un utilisateur à l’application dans le fournisseur d’identité (IdP) désactivera l’utilisateur dans votre forfait Miro Enterprise. L’utilisateur passe d’un état Actif à un état Désactivé (et de la section des utilisateurs correspondante) 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.
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 mettre 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éaffecté automatiquement, mais cela peut être défini lorsque vous manuellement désactivez 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éaffectation du contenu.
-
Réactiver les utilisateurs
Réassigner un utilisateur à l’application ou réactiver son profil dans le fournisseur d’identité 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
Affectez automatiquement les nouveaux utilisateurs aux groupes de facturation à l’aide du SCIM. Une fois votre fournisseur d’identité (IdP) configuré, reliez 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 Parce qu’un groupe d’utilisateurs Miro s’intègre au même modèle d’autorisations utilisé dans tout Miro, vous pouvez partager des tableaux et des espaces directement avec un groupe d’utilisateurs synchronisé depuis votre fournisseur d’identité (IdP), plutôt que d’ajouter les membres individuellement.
-
@mentionner un groupe dans les commentaires Utilisez @mention sur un groupe d’utilisateurs dans les commentaires d’un tableau pour notifier tous ses membres en une seule fois.
- Gérer les groupes via l’API 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 un appel API direct de type suppression - veuillez consulter la documentation ici. Notez que seuls les appels directs supprimeront les utilisateurs. Les événements de suppression initiés par votre fournisseur 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’un 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 l’IdP et dans Miro est la même ; sinon, Miro ne reconnaîtra pas l’utilisateur et un profil Miro en double sera créé sous le nouvel e-mail. La mise à jour de l’e-mail doit se faire 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éclenchera l’envoi d’une notification : l’ancienne et la nouvelle adresse e-mail recevront un message indiquant que l’utilisateur 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 — valeur prise en charge : "Full" |
| Actif | active — valeur prise en charge : "true" ou "false" |
| Photo de profil | photos.^[type==’photo’].value or photos.^[type==photo].value (Okta); photos[type eq "photo"].value (Entra). Il doit s’agir d’une URL textuelle vers l’image. Types de fichiers pris en charge : jpg, jpeg, bmp, png, gif. La taille maximale du fichier à télécharger est de 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 le standard 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 utilisateurs désactivés.
Tous les attributs seront affichés 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, allez dans les paramètres de l’entreprise > Intégrations Enterprise, 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 Provisionnement SCIM, 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 ce nouveau jeton dans votre fournisseur d’identité.
Problèmes éventuels et comment les résoudre
1. Les utilisateurs ne sont pas provisionnés en raison d’une erreur de liste d’autorisations.
Assurez-vous que l’adresse du 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 via SCIM existent aussi 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 l’équipe du service d’assistance Miro.