什么是开发人员管理服务账户？

使用开发人员托管服务账户 (DMSA) 的优势

与传统服务账户相比，使用 DMSA 可以获得许多优势：

• 简化的应用程序管理 - DMSA 由公司管理员使用公司管理员工具中的应用程序管理功能进行安装和管理。与 DMSA 关联的目录用户是在应用程序安装过程中自动创建的。如果使用传统的服务账户，公司管理员必须手动创建和管理账户及其访问权限，这需要与第三方开发人员进行额外的沟通和协调才能安装和配置应用程序。

• 更安全的权限管理 - 给定 DMSA 应用程序的所有必需的公司级别和项目级别工具权限都在应用程序清单中定义，该清单在安装过程中应用于你的公司账户。当应用程序包含新功能并发布更新版本时，开发人员可以通过升级过程请求新权限以供审查和批准。

• 改进的项目访问控制 - 在安装和配置过程中，公司管理员可以准确选择允许 DMSA 应用程序使用的项目。如果使用传统的服务账户，项目访问权限需由公司管理员手动配置和管理，这可能既耗时又费钱，而且可能不够安全，如下所述。

• 更好地了解应用程序使用情况 - 因为 DMSA 是使用应用程序管理安装的，公司管理员可以以应用程序指标的形式了解应用程序使用情况，例如 API 请求的数量、哪些用户安装和/或使用了应用程序、哪些项目被允许使用应用程序，等等。如果使用传统服务账户，既无法收集也无法访问此类指标。

与传统服务账户相关的风险

安装和使用利用传统服务账户的应用程序会带来以下风险：

• API 凭证的不安全传输 - 由于传统服务账户是由公司管理员在 Procore 中手动创建的，因此必须将生成的一组唯一的 API 凭证（client_id 和 client_secret）提供回开发人员，以便成功完成集成设置。不幸的是，这种敏感信息的传输可能会通过电子邮件、短信等不安全的方式进行，从而使公司数据可能容易受到攻击。

• 缺少使用数据 - 如果传统服务账户遭到入侵，则很难跟踪它的使用位置，因为该账户不会生成使用数据。

• 潜在的人为错误 - 手动配置和管理与传统服务账户关联的权限的要求可能容易出错并导致意外的应用程序行为。

DMSA 与传统服务账户有何不同？

以下是 DMSA 和传统服务账户之间的一些主要区别。

安装使用 DMSA 的应用程序后，我会在我的账户中看到什么？

在安装过程中，可能会在代表 DMSA 的公司和/或项目目录工具中创建新的用户记录。DMSA 联系人名称需遵循不同的格式，应用程序名称转换为小写，并由破折号分隔，后跟随机生成的八个字符的 ID。例如，安装应用程序 My DMSA Test App 会在公司目录中创建用户 my-dmsa-test-app-469b1f7f。请务必不要编辑或删除 DMSA 应用程序安装创建的目录用户，因为此操作可能会导致应用程序在运行时出现问题。

DMSA权限管理的最佳实践

管理开发人员管理服务账户（DMSA）的权限需要仔细考虑，以确保应用程序功能和账户安全。 以下是有效管理权限的最佳实践和重要注意事项。

1. 使用项目成员资格的权限标签页- 要管理DMSA项目访问权限，包括添加或删除项目成员资格，请使用应用程序管理下的应用程序中的权限标签页。 此选项适用于公司管理员。

2. 应用程序更新或重新安装的权限重新配置- 每次更新或重新安装应用程序时，公司管理员都必须重新配置已获批项目的列表。 未来需要DMSA访问权限的项目也必须手动添加到允许列表中。

3. 将目录工具用于权限模板- 一些管理员将目录工具与权限模板一起使用来简化DMSA管理:

   • 启用"将（DMSA用户）添加到所有新项目"复选框可以通过自动将DMSA用户添加到未来的项目来简化权限。
   • 重要说明:更新或重新安装应用程序时，应用程序清单中定义的权限不会自动传输到目录工具中的权限模板，可能会影响应用程序功能。 应手动协调这种未对齐情况。

4. 避免手动更新DMSA权限- 通常不建议在目录工具中手动调整DMSA权限，因为这会导致不一致并使账户管理复杂化。

5. 限制DMSA对公司级别目录工具的访问权限- 避免为DMSA用户授予对公司级别目录工具的管理员级别访问权限。 此访问级别允许对你的 Procore 账户中的多个项目和工具进行更改，这可能会影响组织的工作流。 仅在集成绝对必要时才允许此级别的访问权限，并确保彻底了解其含义。

了解 Procore API 身份验证

在 Procore 平台上构建的应用程序使用行业标准OAuth 2.0 授权框架通过API进行身份验证。Procore API支持以下两种授权授予类型或身份验证流程:

• 客户端凭证（DMSA 和传统服务账户） - 大多数数据连接应用程序使用此授权类型通过API进行身份验证。对于客户端凭证授权类型，使用一组API凭据（通过DMSA或传统服务 账户）通过Procore API进行身份验证。对 Procore 平台上的工具和数据的访问受与该账户关联的权限设置的约束。因此，开发人员和公司管理员可以指定应用程序有权访问的确切工具和项目。这是数据连接应用程序的首选方法。有关客户端凭证授权类型的其他信息，请参阅使用OAuth 2.0 客户端凭证授权类型。

• 授权编号（用户登录流程） - Web 服务器和基于浏览器的应用程序通常使用此授权类型通过API进行身份验证。使用授权编号授权类型，应用程序在使用Procore API进行身份验证时代表当前登录的用户运行。在这种情况下，应用程序会假定已登录用户的权限，并且可以访问允许特定用户交互的任何工具、项目或数据。由于在这种授权类型下权限治理可能具有挑战性，因此不建议将其用于数据连接应用程序。有关授权编号授权类型的更多信息，请参阅OAuth 2.0 授权编号授权流程。

无论集成使用的授权授予类型是 authorization_code（登录用户的权限）还是 client_credentials（服务账户/DMSA 权限），Procore 公司管理员最终负责管理其目录用户的权限。

责任共担安全模型

作为软件即服务 (SaaS) 提供商，Procore 在平台安全方面遵循责任共担安全模型。

• 客户对他们安装的集成、他们批准使用这些集成的权限以及他们对与 Procore 提供的这些集成相关联的目录用户（DMSA 或传统）所做的任何更改负责。

• 合作伙伴/开发人员负责处理凭证、调用 API 的代码以及他们对数据的处理方式。客户将密钥提供给开发者，供开发者使用。

• Procore 负责为开发人员提供一种通过 OAuth 请求客户许可的方式，并为客户提供安装和管理应用程序的功能。

另请参阅

• 传统服务账户弃用
• 迁移数据连接应用程序，以使用 DMSA
• 从应用商店安装数据连接应用程序
• 将已获批的项目添加到数据连接应用程序
• 将已获批的项目从数据连接应用程序中删除
• 在公司目录中查看 DMSA