Qu’est-ce qu’un compte de service géré par les développeurs?

Dernière mise à jour
Enregistrer en tant que PDF

Pour les développeurs qui créent des applications à l’aide de composants de connexion de données, nous vous recommandons d’tirer parti de la nouvelle fonction de comptes de service gérés par les développeurs (DMSA ) en tant qu’approche simplifiée pour fournir aux administrateurs Procore les capacité facilement installer et fournir des applications de connexion de données dans leur comptes de compagnie. La fonction DMSA permet aux développeurs de spécifier les permissions exactes de l’outil au niveau de la compagnie et du projet requises pour que leur application s’exécute correctement sur la plateforme Procore. Les administrateurs de la compagnie définissent les projets auxquels l’application peut accéder à l’aide de ces permissions. Les développeurs utilisent des DMSA pour fournir une alternative plus pratique et sécurisée aux comptes de service traditionnels. Les administrateurs de la compagnie bénéficient des DMSA grâce à une meilleure gestion des applications et une meilleure visibilité sur l’utilisation de l’application.

Tous les comptes de service traditionnels expireront le 31 décembre2024.

Les comptes de service traditionnels ont été abandonnés le 9 décembre 2021. À partir du 1er octobre 2024, nous n'autoriserons plus la création de nouveaux comptes de service traditionnels. Les comptes de service traditionnels existants continueront de fonctionner jusqu'au 31 décembre 2024.

Conformément à ce calendrier, les développeurs d'applications de connexion de données qui utilisent actuellement les comptes de service traditionnels sont tenus de mettre à jour leurs applications pour utiliser les comptes de service gérés par les développeurs, et les clients devront installer ces applications mises à jour avant la date de temporisation. Toutes les applications de connexion de données non migrées à la date de temporisation cesseront de fonctionner. Toute application répertoriée sur le marché des marché des applications Procore qui n'utilise pas une méthode prise en charge pour accéder à l' Procore API sera supprimée avant la date de coucher du soleil. Voir Migration des applications de connexion de données pour utiliser les DMSA pour plus d'informations.

Avantages de l'utilisation des comptes de service gérés par les développeurs (DMSA)

L'utilisation des DMSA par rapport aux comptes de service traditionnels présente un certain nombre d'avantages :

Gestion simplifiée des applications - Les DMSA sont installés et gérés par les administrateurs de la compagnie à l'aide de la fonction de gestion des applications dans l'outil Admin de la compagnie. L'utilisateur du répertoire associé au DMSA est automatiquement créé dans le cadre du processus d'installation de l'application. Avec les comptes de service traditionnels, les administrateurs de l'entreprise doivent créer et gérer manuellement le compte et ses permissions d'accès, ce qui nécessite une communication et une coordination supplémentaires avec le développeur tiers pour installer et configurer l'application.
Gestion des permissions plus sécurisée - Toutes les permissions requises au niveau de l'entreprise et de l'outil au niveau du projet pour une application DMSA donnée sont définies dans un manifeste d'application qui est appliqué à votre compte d'entreprise pendant le processus d'installation. Lorsqu'une application intègre de nouvelles fonctionnalités et publie une version mise à jour, le développeur peut demander de nouvelles permissions via le processus de mise à niveau pour être examinée et approuvée.
Contrôle d'accès au projet amélioré - Au cours du processus d'installation et de configuration, les administrateurs de la compagnie sélectionnent exactement les projets que l'application DMSA est autorisée à utiliser. Avec les comptes de service traditionnels, l'accès au projet est configuré et géré manuellement par l'administrateur de la compagnie, ce qui peut prendre du temps et être coûteux, et peut être moins sécurisé comme décrit ci-dessous.
Meilleures informations sur l'utilisation des applications - Étant donné que les DMSA sont installés à l'aide de la gestion des applications, les administrateurs de l'entreprise ont une visibilité sur l'utilisation des applications sous forme de mesures d'application telles que le nombre de demandes d'API, les utilisateurs qui ont installé et/ou utilisé une application, les projets autorisés. pour utiliser une application, et plus encore. Avec les comptes de service traditionnels, ces mesures ne sont ni recueillies ni accessibles.

Risques associés aux comptes de service traditionnels

L'installation et l'utilisation d'applications qui utilisent des comptes de service traditionnels comportent les risques suivants :

Transmission non sécurisée des informations d'identification de l'API - Étant donné qu'un compte de service traditionnel est créé manuellement dans Procore par un administrateur de la compagnie, l'ensemble unique d'informations d'identification d'API générées (client_id et client_secret) doit être renvoyé au développeur afin de terminer avec succès la configuration de l'intégration. La transmission de ces informations sensibles peut malheureusement se faire par des moyens non sécurisés tels que les courriels, les SMS, etc., laissant les données de l'entreprise potentiellement vulnérables.
Manque de données d'utilisation - Si un compte de service traditionnel est compromis, il est difficile de suivre où il est utilisé, car le compte ne génère pas de données d'utilisation.
Potentiel d'erreur humaine - L'exigence de configurer et de gérer manuellement les permissions associées à un compte de service traditionnel peut être sujette aux erreurs et conduire à un comportement d'application inattendu.

Comment un DMSA diffère-t-il d’un service traditionnel compte?

Voici quelques-unes des principales différences entre les DMSA et les comptes de services traditionnels.

	Compte de service géré des développeurs	Compte de service traditionnel
Création de compte	Un utilisateur du répertoire associé à la DMSA est automatiquement créé dans l’outil Répertoire de la compagnie et/ou du projet.	Un compte de service traditionnel doit être créé et géré manuellement par une administrateur de compagnie.
Autorisation	Un seul ensemble d’informations d’identification (client_id, client_secret) est utilisé pour accéder à toutes les compagnies où l’application est installée.	Chaque service compte créé dans une compagnie par un administrateur a un ensemble unique d’informations d’identification, nécessitant des coordination manuelles avec le développeur pour une intégration réussie.
Autorisations	Les permissions requises sont définies par le développeur dans le manifeste de l’application et appliquées automatiquement lors de l’installation.	Les permissions pour chaque compte de service doivent être configurées manuellement par un administrateur de compagnie.
Configuration du projet	Pendant l’installation, vous pouvez sélectionner les projets dans lesquels l’application DMSA est autorisée à s’exécuter. Une fois l’application installée, vous pouvez ajouter ou supprimer des projets autorisés si nécessaire.	L’accès au projet et doit être configuré et géré manuellement par l’administrateur de la compagnie.
Gestion des applications	Les applications activées par DMSA sont facilement installées à partir du marché des applications ou en tant qu’installation personnalisée. Outil Admin de la compagnie (gestion des applications) utilisé pour désinstaller/réinstaller.	Toutes les aspects des services traditionnels compte d’installation et de gestion des services doivent être traitées manuellement par un administrateur de compagnie.

Que verra-je dans mon compte après l’installation d’une application qui utilise un DMSA?

Au cours du processus d'installation, un nouvel enregistrement d'utilisateur peut être créé dans l'outil Répertoire de la compagnie et/ou du projet qui représente le DMSA. Le nom du contact DMSA suit un format distinct avec le nom de l'application converti en minuscules et séparé par des tirets suivis d'un identifiant généré aléatoirement à huit caractères. Par exemple, l'installation de l'application My DMSA Test App créerait l'utilisateur my-dmsa-test-app-469b1f7f dans le répertoire de la compagnie. Il est important de ne pas modifier ou supprimer les utilisateurs du répertoire créés par les installations d'applications DMSA, car cela pourrait entraîner des problèmes de fonctionnement de l'application.

Meilleures pratiques pour la gestion des autorisations DMSA

La gestion des autorisations pour un compte de service géré de développeur (DMSA) implique une attention particulière pour garantir la fonctionnalité de l’application et la sécurité du compte. Vous trouverez ci-dessous les meilleures pratiques et les considérations importantes à prendre en compte pour gérer efficacement les autorisations.

Utiliser l’onglet Permissions pour l’adhésion au projet - Pour gérer l’accès au projet DMSA, y compris l’ajout ou la suppression d’adhésions aux projets, utilisez l’onglet Permissions dans l’application sous Gestion des applications. Cette option est disponible pour les administrateurs de compagnie.
Reconfiguration des permissions lors de la mise à jour ou de la réinstallation de l’application - Chaque fois qu’une application est mise à jour ou réinstallée, les administrateurs de la compagnie doivent reconfigurer la liste des projets autorisés. Les projets futurs nécessitant un accès DMSA doivent également être ajoutés manuellement à la liste autorisée.
Utilisation de l’outil Répertoire pour les modèles de permissions : certains administrateurs utilisent l’outil Répertoire avec un modèle de permissions pour rationaliser la gestion DMSA :
- L’activation de la case à cocher « Ajouter [utilisateur DMSA] à tous les nouveaux projets » peut simplifier les autorisations en ajoutant automatiquement l’utilisateur DMSA aux projets futurs.
- Remarque importante : Lorsqu’une application est mise à jour ou réinstallée, les autorisations définies dans le manifeste de l’application ne sont pas automatiquement transférées vers le modèle de permissions dans l’outil Répertoire, ce qui peut affecter les fonctionnalités de l’application. Ce désalignement doit être résolu manuellement.
Évitez les mises à jour manuelles des permissions DMSA - L’ajustement manuel des permissions DMSA dans l’outil Répertoire est généralement déconseillé, car cela peut entraîner des incohérences et compliquer la gestion des comptes.
Limiter l’accès DMSA à l’outil Répertoire au niveau de la compagnie - Évitez d’accorder à l’utilisateur DMSA un accès de niveau administrateur à l’outil Répertoire au niveau de la compagnie. Ce niveau d’accès permet d’apporter des modifications à plusieurs projets et outils de votre compte Procore, ce qui peut avoir un impact sur les flux de travail de votre organisation. N’autorisez ce niveau d’accès que si cela est absolument nécessaire pour l’intégration et assurez-vous de bien comprendre les implications.

Comprendre l'authentification API Procore

Les applications construites sur la plate-forme Procore utilisent le cadre d'autorisation standard OAuth 2.0 pour l'authentification avec l'API. L'API Procore prend en charge les deux types d'attribution d'autorisation ou flux d'authentification suivants :

Identifiants du client (DMSA et comptes de service traditionnels) - La plupart des applications de connexion de données utilisent ce type d'autorisation pour l'authentification avec l'API. Avec le type d'attribution Identifiants du client, un seul ensemble d'informations d'identification d'API est utilisé (via un compte de service DMSA ou traditionnel) pour s'authentifier auprès de l'API Procore. L'accès aux outils et aux données de la plateforme Procore est régi par les paramètres de permissions associés à ce compte. En conséquence, les développeurs et les administrateurs de l'entreprise peuvent spécifier les outils et les projets exacts auxquels une application a accès. Il s'agit de l'approche préférée pour les applications de connexion de données. Pour plus d'informations sur le type d'octroi des informations d'identification du client, consultez Utilisation du type d'octroi des informations d'identification du client OAuth 2.0 .
Code d'autorisation (flux de connexion de l'utilisateur) - Le serveur Web et les applications basées sur un navigateur utilisent souvent ce type d'autorisation pour l'authentification avec l'API. Avec le type d'attribution de code d'autorisation, l'application fonctionne au nom de l'utilisateur actuellement connecté lors de l'authentification avec l'API Procore. Dans ce scénario, l'application assume les permissions de l'utilisateur connecté et a accès à tout outil, projet ou donnée avec lequel un utilisateur particulier est autorisé à interagir. Étant donné que la gouvernance des permissions peut être difficile avec ce type d'octroi, il n'est pas recommandé pour les applications de connexion de données. Pour plus d'informations sur le type d'attribution de code d'autorisation, consultez Flux d'attribution de code d'autorisation OAuth 2.0 .

Les administrateurs de la compagnie Procore sont en fin de compte responsables de la gestion des permissions des utilisateurs de leur répertoire, quel que soit le type d'autorisation utilisé par une intégration - permission_code (permissions de l'utilisateur connecté) ou client_credentials (compte de service/permissions DMSA).

Modèle de sécurité à responsabilité partagée

En tant que fournisseur de logiciel en tant que service (SaaS), Procore suit un modèle de responsabilité partagée dans le contexte de la sécurité de la plateforme.

Les clients sont responsables des intégrations qu'ils installent, des permissions qu'ils approuvent pour l'utilisation de ces intégrations et de toutes les modifications qu'ils apportent aux utilisateurs du répertoire (DMSA ou traditionnel) associés à ces intégrations en dehors de ce que Procore fournit.
Les partenaires/développeurs sont responsables du traitement des informations d'identification, du code qui appelle l'API et de ce qu'ils font avec les données. Le client fournit les clés aux développeurs à utiliser par les développeurs.
Procore est chargé de fournir aux développeurs un moyen de demander les permissions des clients via OAuth et aux clients la possibilité d'installer et de gérer des applications.

Fin des comptes de service traditionnels