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

Pour les développeurs qui créent des applications à l’aide de composants de connexion de données, nous recommandons de tirer parti de la nouvelle fonctionnalité Comptes de service gérés par les développeurs (CSGD) comme approche simplifiée pour fournir aux administrateurs Procore la possibilité d’installer et de provisionner facilement des applications de connexion de données dans leurs comptes d’entreprise. La fonctionnalité DMSA permet aux développeurs de spécifier les autorisations exactes d’outils au niveau entreprise et niveau Projet qui sont requises pour que leur application fonctionne correctement sur la plateforme Procore. Les administrateurs Procore définissent les projets auxquels l’application peut accéder à l’aide de ces autorisations. Les développeurs utilisent les DMSA pour fournir une alternative plus pratique et plus sécurisée aux comptes de service traditionnels. Les administrateurs Procore bénéficient des DMSA grâce à une meilleure gestion des applications et à une meilleure visibilité de l’utilisation des applications.

Tous les comptes de service traditionnels ont pris fin le 18 mars 2025.

Les comptes de service traditionnels ont été abandonnés le 9 décembre 2021. À compter du 21 janvier 2025, nous n’autoriserons plus la création de nouveaux comptes de service traditionnels. Les comptes de service traditionnels existants continueront de fonctionner jusqu’au 18 mars 2025.

Conformément à ce calendrier, les développeurs d’applications de connexion de données qui utilisent actuellement des comptes de service traditionnels sont tenus de mettre à jour leurs applications pour utiliser des comptes de service gérés par les développeurs, et les clients devront installer ces applications mises à jour avant la date d’extinction. Toutes les applications de connexion de données qui n’ont pas été migrées à la date d’expiration cesseront de fonctionner. Toute application répertoriée sur Procore App Marketplace qui n’utilise pas une méthode prise en charge pour accéder à l’Procore API sera supprimée à la date d’expiration. Pour plus d’informations, reportez-vous à la section Migration des applications de connexion de données vers l’utilisation des DMSA.

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

Il y a un certain nombre d’avantages à tirer de l’utilisation des DMSA par rapport aux comptes de service traditionnels:

• Gestion simplifiée des applications - Les DMSA sont installés et gérés par les administrateurs de l’entreprise à l’aide de la fonction de gestion des applications de l’outil Admin de l’entreprise. L’utilisateur de l’annuaire associé au CSGD 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 autorisations 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 autorisations plus sécurisée : toutes les autorisations d’outils requises au niveau entreprise et 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 autorisations via le processus de mise à niveau pour qu’elles soient révisées et approuvées.

• Amélioration du contrôle d’accès aux projets - Au cours du processus d’installation et de configuration, les administrateurs de l’entreprise 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 l’entreprise, ce qui peut prendre du temps et être coûteux, et peut être moins sécurisé comme décrit ci-dessous.

• Meilleur aperçu de 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 la 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 à utiliser une application, etc. Avec les comptes de service traditionnels, ces mesures ne sont ni collectées 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 Identifiants d’API - Étant donné qu’un compte de service traditionnel est créé manuellement dans Procore par un administrateur Procore, l’ensemble unique d’identifiants d’API générés (client_id et client_secret)) doit être fourni au développeur afin de mener à bien 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 e-mail, message texte, etc., ce qui entreprise données rend potentiellement vulnérable.

• Manque de données d’utilisation - Si un compte de service traditionnel est compromis, il est difficile de savoir où il est utilisé, car le compte ne génère pas de données d’utilisation.

• Risque d’erreur humaine : la nécessité de configurer et de gérer manuellement les autorisations associées à un compte de service traditionnel peut être sujette aux erreurs et entraîner un comportement inattendu de l’application.

En quoi un CSGD diffère-t-il d’un compte de service traditionnel ?

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

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

Au cours du processus d’installation, un nouvel enregistrement d’utilisateur peut être créé dans l’outil Annuaire de l’entreprise et/ou du projet qui représente les CSGD. Le nom du contact DMSA suit un format distinct, le nom de l’application étant converti en minuscules et séparé par des tirets suivis d’un identifiant de huit caractères généré de manière aléatoire. Par exemple, l’installation de l’application de test application Mon CSGD créerait le utilisateur my-dmsa-test-app-469b1f7fdans le Entreprise Annuaire. Il est important de ne pas modifier ou supprimer les utilisateurs d’annuaire créés par l’installation 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 services gérés pour les développeurs (CSGD) 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.

1. Utiliser l’onglet Autorisations pour l’appartenance au projet - Pour gérer l’accès au projet DMSA, y compris l’ajout ou la suppression d’adhésions à des projets, utilisez l’onglet Autorisations dans l’application sous Gestion des applications. Cette option est disponible pour les administrateurs de l’entreprise.

2. Reconfiguration des autorisations 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 l’entreprise doivent reconfigurer la liste des projets autorisés. Les futurs projets nécessitant un accès aux CSGD doivent également être ajoutés manuellement à la liste des projets autorisés.

3. Utilisation de l’outil Annuaire pour les modèles d’autorisation - Certains administrateurs utilisent l’outil Annuaire avec un modèle d’autorisation pour rationaliser la gestion des CSGD :

   • L’activation de la case à cocher « Ajouter [utilisateur CSGD] à tous les nouveaux projets » peut simplifier les autorisations en ajoutant automatiquement l’utilisateur CSGD 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 d’autorisations dans l’outil Annuaire, ce qui peut affecter les fonctionnalités de l’application. Ce désalignement doit être corrigé manuellement.

4. Évitez les mises à jour manuelles des autorisations DMSA - L’ajustement manuel des autorisations DMSA dans l’outil Annuaire est généralement déconseillé, car cela peut entraîner des incohérences et compliquer la gestion des comptes.

5. Limiter l’accès des CSGD à l’outil d’annuaire au niveau entreprise : évitez d’accorder à l’utilisateur des CSGD un accès de niveau administrateur à l’outil Annuaire au niveau entreprise. 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 de l’API Procore

Les applications basées sur l’plateforme Procore utilisent le cadre OAuth 2.0>>> d’autorisation standard de l’industrie pour l’authentification avec l’API. L’API Procore API prend en charge les deux types 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 s’authentifier auprès de l’API. Avec le type d’autorisation Identifiants du client, un seul ensemble d’identifiants d’API est utilisé (via un CSGD ou un compte de service traditionnel) pour s’authentifier auprès de l’Procore API. L’accès aux outils et aux données de la plateforme Procore est régi par les paramètres d’autorisation associés à ce compte. Par conséquent, les développeurs et les administrateurs Procore peuvent spécifier les outils et 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 Identifiants client, voir Utilisation du type d’octroi Identifiants client OAuth 2.0 .

• Code d’autorisation (flux de connexion de l’utilisateur) : les applications basées sur un serveur Web et un navigateur utilisent souvent ce type d’autorisation pour s’authentifier auprès de l’API. Avec le type d’octroi Code d’autorisation, l’application fonctionne au nom de l’utilisateur actuellement connecté lors de l’authentification avec l’API Procore API. Dans ce scénario, l’application assume les autorisations de l’utilisateur connecté et a accès à tous les outils, projets ou données avec lesquels cet utilisateur particulier est autorisé à interagir. Étant donné que la gouvernance des autorisations peut être difficile avec ce type d’accord, elle n’est pas recommandée pour les applications de connexion de données. Pour plus d’informations sur le type d’octroi de code d’autorisation, consultez <<<OAuth 2.0>>> Flux d’octroi de code d’autorisation.

Les administrateurs Procore sont responsables en dernier ressort de la gestion des autorisations des utilisateurs de leur annuaire, quel que soit le type d’autorisation utilisé par une intégration - <<<authorization_code (autorisations de l'utilisateur connecté) ou client_credentials (autorisations de compte de service/CSGD).

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

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

• Les clients sont responsables des intégrations qu’ils installent, des autorisations qu’ils approuvent pour l’utilisation de ces intégrations et de toute modification qu’ils apportent aux utilisateurs de l’annuaire (DMSA ou traditionnel) associés à ces intégrations en dehors de ce que Procore fournit.

• Les partenaires/développeurs sont responsables de la gestion 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 pour qu’ils les utilisent.

• Procore est chargé de fournir aux développeurs un moyen de demander les autorisations des clients via OAuth et aux clients la possibilité d’installer et de gérer des applications.