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.

Les comptes de service traditionnels ont été abandonnés le 9 décembre 2021. Tous les comptes de service traditionnels expireront à une date future qui sera annoncée. En raison de cette dépréciation, 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 les DMSA, et les clients devront installer ces applications mises à jour avant la date d'expiration. Voir Abandon des comptes de service traditionnels pour plus de détails.

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.

Implications de l'octroi de permissions d'administrateur de répertoire aux applications

Les administrateurs de la compagnie sont fortement mis en garde contre l'octroi d'un accès administrateur à l'outil Répertoire au niveau de la compagnie aux applications utilisant des DMSA ou des comptes de service traditionnels. Les applications avec ce niveau d'accès le plus élevé ont la capacité d'apporter des modifications qui peuvent affecter négativement tous les outils d'un projet entier ou tous les projets de l'ensemble du compte d'entreprise Procore de votre organisation. Bien que certaines applications puissent avoir besoin de cela pour fonctionner, nous vous recommandons d'examiner attentivement la nécessité de l'intégration et de comprendre l'impact avant de l'autoriser.

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.

dépréciation des comptes de service traditionnels