Entwicklern, die Anwendungen unter Verwendung von Datenverbindungskomponenten erstellen, empfehlen wir, die neue Funktion Entwicklerverwaltete Servicekonten (DMSA) zu nutzen, um Procore-Administratoren die Möglichkeit zu geben, Datenverbindungsanwendungen in ihren Unternehmenskonten einfach zu installieren und bereitzustellen. Die DMSA-Funktion ermöglicht es Entwicklern, die genauen Tool-Berechtigungen auf Unternehmens- und Projektebene festzulegen, die erforderlich sind, damit ihre Anwendung auf der Procore-Plattform ordnungsgemäß läuft. Unternehmensadministratoren legen fest, auf welche Projekte die Anwendung mit diesen Berechtigungen zugreifen kann. Entwickler nutzen DMSAs, um eine bequemere und sicherere Alternative zu herkömmlichen Servicekonten anzubieten. Unternehmensadministratoren profitieren von DMSAs durch ein verbessertes Anwendungsmanagement und einen besseren Einblick in die Anwendungsnutzung.
Alle traditionellen Servicekonten werden am 31. Dezember 2024auslaufen.
Traditionelle Servicekonten wurden am 9. Dezember 2021 eingestellt. Ab dem 1. Oktober 2024 werden wir die Erstellung neuer Konten für traditionelle Dienstleistungen nicht mehr zulassen. Bestehende traditionelle Servicekonten sind bis zum 31. Dezember 2024 weiterhin funktionsfähig.
In Übereinstimmung mit diesem Zeitplan müssen Entwickler von Datenverbindungsanwendungen, die derzeit herkömmliche Dienstkonten verwenden, ihre Anwendungen aktualisieren,um Dateiname="">Entwicklerverwaltete Dienstkonten zu verwenden<a target="_blank" title=" " href.path="//faq/what-is-developer-managed-service-account" href., und die Kunden müssen diese aktualisierten Anwendungen vor dem Ablaufdatum installieren. Alle Datenverbindungsanwendungen, die bis zum Ablaufdatum nicht migriert wurden, funktionieren nicht mehr. Alle auf dem Procore-App Marketplace aufgeführten Anwendungen, die keine unterstützte Methode für den Zugriff auf die Procore API verwenden, werden bis zum Ablaufdatum entfernt. Siehe Migration von Datenverbindungsanwendungen zur Verwendung von DMSAs für zusätzliche Informationen.
There are a number of benefits to be gained by using DMSAs over traditional service accounts:
Simplified App Management - DMSAs are installed and managed by company administrators using the App Management feature in the Company Admin tool. The Directory user associated with the DMSA is automatically created as part of the application installation process. With traditional service accounts, company administrators have to manually create and manage the account and its access permissions, which requires additional communication and coordination with the third-party developer to get the application installed and configured.
More Secure Permissions Management - All required company level and project level tool permissions for a given DMSA application are defined in an application manifest that is applied to your company account during the installation process. When an application incorporates new functionality and releases an updated version, the developer can request new permissions via the upgrade process to be reviewed and approved.
Improved Project Access Control - During the installation and configuration process, company administrators select exactly which projects the DMSA application is allowed to use. With traditional service accounts, project access is configured and managed manually by the company administrator, which can be time consuming and costly, and may be less secure as described below.
Better Insight on Application Usage - Because DMSAs are installed using App Management, company administrators have visibility into application usage in the form of application metrics such as the number of API requests, which users have installed and/or used an application, which projects are permitted to use an application, and more. With traditional service accounts, such metrics are neither gathered nor accessible.
Installing and using applications that utilize traditional service accounts comes with the following risks:
Unsecured Transmission of API Credentials - Because a traditional service account is created manually in Procore by a company administrator, the unique set of generated API credentials (client_id and client_secret) must be provided back to the developer in order to successfully complete the integration setup. The transmission of this sensitive information can unfortunately occur through unsecured means such as email, text message, etc., leaving company data potentially vulnerable.
Lack of Usage Data - If a traditional service account becomes compromised, it is difficult to track where it is being used because the account does not generate usage data.
Potential for Human Error - The requirement to manually configure and manage the permissions associated with a traditional service account can be error prone and lead to unexpected application behavior.
Hier sind einige der Hauptunterschiede zwischen DMSAs und traditionellen Servicekonten.
| Entwicklerverwaltete Servicekonten | Traditionelles Servicekonto | |
| Kontoerstellung |
|
|
| Autorisierung |
|
|
| Berechtigungen |
|
|
| Projektkonfiguration |
|
|
| App-Verwaltung |
|
|
During the installation process, a new user record may be created in the Company and/or Project Directory tool that represents the DMSA. The DMSA contact name follows a distinct format with the application name converted to lower case and separated by dashes followed by an eight-character randomly generated id. For example, installing the application My DMSA Test App would create the user my-dmsa-test-app-469b1f7f in the Company Directory. It is important that you do not edit or delete directory users created by DMSA application installations as this may cause problems with the operation of the application.
Die Verwaltung von Berechtigungen für ein Developer Managed Service Account (DMSA) erfordert sorgfältige Überlegungen, um die Anwendungsfunktionalität und die Kontosicherheit zu gewährleisten. Im Folgenden finden Sie bewährte Praktiken und wichtige Überlegungen für eine effektive Verwaltung von Berechtigungen.
Verwenden der Registerkarte "Berechtigungen" für die Projektmitgliedschaft - Um den DMSA-Projektzugriff zu verwalten, einschließlich des Hinzufügens oder Entfernens von Projektmitgliedschaften, verwenden Sie die Registerkarte Berechtigungen in der App unter App-Verwaltung. Diese Option steht Unternehmensadministratoren zur Verfügung.
Neukonfiguration von Berechtigungen bei App-Update oder Neuinstallation - Jedes Mal, wenn eine App aktualisiert oder neu installiert wird, müssen Unternehmensadministratoren die Liste der zulässigen Projekte neu konfigurieren. Zukünftige Projekte, die einen DMSA-Zugang erfordern, müssen ebenfalls manuell in die zulässige Liste aufgenommen werden.
Verwenden des Adressbuch-Tools für Berechtigungsvorlagen - Einige Administratoren verwenden das Adressbuch-Tool mit einer Berechtigungsvorlage, um die DMSA-Verwaltung zu optimieren:
Vermeiden Sie manuelle Aktualisierungen von DMSA-Berechtigungen - Von der manuellen Anpassung der DMSA-Berechtigungen innerhalb des Adressbuch-Tools wird im Allgemeinen abgeraten, da dies zu Inkonsistenzen führen und die Kontoverwaltung erschweren kann.
Beschränken Sie den DMSA-Zugriff auf das Adressbuch-Tool auf Unternehmensebene- Vermeiden Sie es, dem DMSA-Benutzer Admin-Zugriff auf das Adressbuch-Tool auf Unternehmensebene zu gewähren. Diese Zugriffsebene ermöglicht Änderungen über mehrere Projekte und Tools in Ihrem Procore-Konto hinweg, was sich auf die Arbeitsabläufe Ihres Unternehmens auswirken kann. Erlauben Sie diese Zugriffsebene nur, wenn dies für die Integration unbedingt erforderlich ist, und stellen Sie sicher, dass Sie die Auswirkungen gründlich verstehen.
Applications built on the Procore platform use the industry standard OAuth 2.0 Authorization Framework for authentication with the API. The Procore API supports the following two authorization grant types, or authentication flows:
Authorization Code (user login flow) - Web server and browser-based applications often use this grant type for authentication with the API. With the Authorization Code grant type, the application operates on behalf of the currently logged in user when authenticating with the Procore API. In this scenario, the application assumes the permissions of the logged in user and has access to any tool, project, or data that particular user is allowed to interact with. Because permissions governance can be challenging under this grant type, it is not recommended for data connection applications. For additional information on the Authorization Code grant type, see OAuth 2.0 Authorization Code Grant Flow.
Procore company administrators are ultimately responsible for managing the permissions of their directory users regardless of the authorization grant type used by an integration - authorization_code (logged in user's permissions) or client_credentials (service account/DMSA permissions).
As a Software as a Service (SaaS) provider, Procore follows a shared responsibility model in the context of platform security.
Customers are responsible for the integrations they install, permissions they approve for those integrations to use, and any changes they make to the directory users (DMSA or traditional) associated with those integrations outside of what Procore provides.
Partners/Developers are responsible for the handling of credentials, the code that calls the API and what they do with the data. The customer provides the keys to the Developers to be used by the Developers.
Procore is responsible for providing developers a means to request permissions of customers via OAuth and customers the ability to install and manage applications.