Permissions（权限）

This section explains the different permissions required to use the Developer Console and the OSDK. These roles and permissions can be managed in the Roles section of Foundry Settings.

User permissions

:::callout{theme="neutral" title="Beta"} Compass-managed user permissions are in the beta phase of development and may not be available for your enrollment.

See User permissions [Legacy] if Compass-managed user permissions are not available on your enrollment. :::

Applications you create in Developer Console automatically inherit permissions, such as those enforced by roles, markings, or organizations, from their parent project or folder.

If your project uses the default role set, then a Developer Console application user could have one of the following roles below, which are fully configurable:

• Viewer: Can view the application details, the hosted website if the application is hosted on Foundry, and use the generated OSDK to develop the application. A Viewer cannot edit the application information, add or modify entities, or generate new versions of the OSDK.
• Editor: Can edit the application information and OAuth parameters, add or modify entities, and generate new versions of the OSDK.
• Owner: Same permissions as an Editor, and can share the application with other developers.

:::callout{theme="neutral"} An application will appear in the Developer Console home page list only if the user has at least the View application configuration (third-party-application:view-application-config) operation on it, granted through the Viewer role by default. :::

Linked OAuth client

Developer Console always links a custom application to an OAuth client, which you can manage at the organization level in Control Panel. To change the OAuth client's authentication settings, you must have access to workflows such as Enable third-party applications and Manage third-party application secret, typically granted under the Third-party application administrator role in Control Panel's Organization permissions extension. This role also grants you the ability to create linked OAuth clients, which is required to create custom applications in Developer Console.

You can also manage OAuth clients on a per-client basis in the Sharing & tokens section of your Developer Console application using the OAuth2 client role context. For example, you can configure a custom role with only the Rotate third-party application client secret (multipass:rotate-client-secret) operation, and grant it to users who should only have the ability to rotate the client secret for a specific application.

Use the Manage OAuth client tab of the Sharing & tokens section when editing your application to share the client with organizations, users, and groups.

:::callout{theme="neutral"} Linked OAuth client permissions may be converged with application permissions in the future. :::

Create applications

To create a new application, you need the:

• Create application (third-party-application:create-application) operation on the selected folder, granted through Owner or Editor roles by default.
• Create third-party applications workflow on the selected organization, typically granted through the Third-party application administrator role in Control Panel as outlined above.

Website hosting

• To view a website hosted on Foundry, you must have the View application website (third-party-application:view-application-website) operation on the Developer Console application, granted through the Viewer role by default. If you want users to view the website without being able to access the application configuration in Developer Console, you can create a custom project role that only grants this operation.

• To deploy a website on Foundry, you must have the Deploy application website (third-party-application:deploy-application-website) operation on the Developer Console application, granted through the Editor role by default.

• A Foundry user with the Information Security Officer role may approve or decline a domain creation request.

Learn more about hosting an OSDK application on Foundry.

Application permissions

The Developer Console supports two types of applications:

• Client-facing: Frontend services, including web, desktop, or mobile applications. These applications must not be used to store client credentials.
• Backend service: An application to support a backend workflow, such as an application service or daemon. The applications may be used to securely store client credentials.

The same application could include both a client-facing and backend type. The type of application you create will determine which permission type and OAuth workflow may be used, as explained below.

Permission types

When creating an application, you must choose the permission type used to access the application data. Two permissions types are available:

• User permissions: A user's permissions will determine what they can read and write to the Foundry Ontology. This permission type will use the Authorization code grant OAuth workflow.
• Application permissions: Your application will use a generated service user for permissions rather than applying user permissions. This permission type will use the Client credentials grant OAuth workflow.

:::callout{theme="warning"} Client-facing applications must use the user permissions option and the Authorization code grant OAuth workflow. :::

Example

Let’s say you are building an application that displays vehicle data.

If you want users to only view Cars they have permission to access, choose to apply User permissions. If you want users to be able to view all Bikes, regardless of user permissions, choose to apply Application permissions to grant separate permissions for the application using a generated service user.

If you want users to view all Cars they have access to view AND all Bikes, choose to use both permissions options.

Resource access restrictions

As you add resources to your application's SDK, those resources and their dependents will be automatically added to the application's resource access restrictions. While users must have relevant permissions for the resources, the resource access restrictions ensure that users can only access the resources that are approved for this application through the given OAuth token.

For example, when adding new object types, link types, action types, or functions to your SDK configuration, any required underlying datasets or related resources will be added to the resource access restrictions.

For your application to function correctly, you may need to manually manage the restrictions when dependencies change or when removing resources.

When dependencies change

If the required dependencies for the resources in your application's SDK change after you added them, you should update your application's resource access restrictions to include the changed dependencies. You can do this via the Developer Console where you can view a warning if an application's restrictions are outdated and a guided workflow for correcting them. For example, this may be required if a new backing dataset is configured for an object type that is already included in your application SDK.

Example warning shown on the Application SDK page when outdated dependencies are detected.

Example correction workflow for outdated dependencies, in this case showing a missing dataset for an object type.

When removing resources

If you create a new version of your application SDK that removes previously included resources, usage of the current version of your application will break if these resources are immediately removed from the resource access restrictions. To prevent this from happening, you must remove previously included resources from the SDK but keep these resources in the resource access restrictions until you have upgraded all your clients to the new version of the application, after which it will be safe to remove the previously included resources from the restrictions as well.

When you remove a resource from the SDK, the Developer Console application will display a warning confirming whether you also want to remove them from the restrictions or keep them in. You can clean up old resources later from the OAuth & restrictions page.

Example warning shown on the Application SDK page when a resource is being removed.

Example clean-up workflow for old resources present on the resource access restrictions from previous SDK versions.

Migrate to Compass-managed user permissions

:::callout{theme="warning"} As of February 2026, Compass-managed user permissions are in the beta phase of development. If your enrollment does not have this feature enabled, then you can refer to the legacy user permissions section below. As Compass-managed user permissions progress toward general availability, you should refer to the migration steps below to migrate to Compass-managed user permissions. :::

User permissions [Legacy]

Instead of applications inheriting project permissions, Developer Console users are automatically set as the Owner of the applications they create. The application owner must then share the application with other developers and grant permissions to given users from the Sharing & tokens section of their application.

You can delete Developer Console applications in the Danger zone panel of the Overview section of a given application. Unlike a Compass resource's trashing workflow, deleted applications cannot be restored.

Follow the migration steps below to ensure your Developer Console applications are managed by Compass.

Migration steps

The Migrate legacy application to Compass (third-party-application:migrate-application-to-compass) operation is required to migrate an application, granted through the Owner role by default.

1. Open your application and select Migrate application to project.

1. Follow the instructions in the Migration to Compass resource pop-up modal to select a location.

1. Review the permission changes and select Submit to confirm.

After migration, your application will appear in the selected location. You can now perform actions on the application like those on any other Compass resource, such as moving, sharing, and trashing.

Website viewer permissions

Previously, you could use the Sharing & tokens section of the application to grant users permission to view the hosted website, but not view the application's configuration.

While this is no longer available by default for Compass-managed applications, you can create a custom project role to maintain separate viewing permissions. To prevent breaks to existing workflows, assign this role on the project or folder prior to migration. This ensures the desired group of users can access the website but not view the application's configuration in Developer Console.

Marketplace applications

Developer Console applications deployed through Marketplace were previously not created in the same location as other installation resources. With the migration to Compass-managed user permissions, new applications that are installed through Marketplace will also be created in the location you provide.

Migrating a packaged application from a Marketplace product will not automatically migrate its previously deployed installations. Each installation must also be migrated independently using the migration steps. If the installation is locked, you may be prompted to unlock it beforehand so that you can move the application to that location.

---

中文翻译

权限

本节将说明使用开发者控制台(Developer Console)和OSDK所需的不同权限。这些角色和权限可在Foundry设置(Foundry Settings)的角色(Roles)部分进行管理。

用户权限

:::callout{theme="neutral" title="测试版(Beta)"} Compass管理的用户权限目前处于开发阶段的测试版(Beta)，您的注册环境可能无法使用此功能。

如果您的注册环境无法使用Compass管理的用户权限，请参阅用户权限[旧版]。 :::

您在开发者控制台中创建的应用程序会自动从其父级项目或文件夹(project or folder)继承权限，例如由角色(roles)、标记(markings)或组织(organizations)强制执行的权限。

如果您的项目使用默认角色集，则开发者控制台应用程序用户可能拥有以下完全可配置的角色之一：

• 查看者(Viewer)： 可以查看应用程序详情、托管网站（如果应用程序托管在Foundry上），并使用生成的OSDK开发应用程序。Viewer无法编辑应用程序信息、添加或修改实体，也无法生成新版本的OSDK。
• 编辑者(Editor)： 可以编辑应用程序信息和OAuth参数、添加或修改实体，并生成新版本的OSDK。
• 所有者(Owner)： 拥有与Editor相同的权限，并且可以与其他开发者共享应用程序。

:::callout{theme="neutral"} 只有当用户至少拥有应用程序的查看应用程序配置(View application configuration)（third-party-application:view-application-config）操作权限（默认通过Viewer角色授予）时，该应用程序才会出现在开发者控制台主页列表中。 :::

关联的OAuth客户端

开发者控制台始终将自定义应用程序与OAuth客户端(OAuth client)关联，您可以在控制面板(Control Panel)的组织级别进行管理。要更改OAuth客户端的身份验证设置，您必须有权访问诸如启用第三方应用程序(Enable third-party applications)和管理第三方应用程序密钥(Manage third-party application secret)等工作流程，这些权限通常通过控制面板的组织权限(Organization permissions)扩展中的第三方应用程序管理员(Third-party application administrator)角色授予。此角色还授予您创建关联OAuth客户端的能力，这是在开发者控制台中创建自定义应用程序所必需的。

您还可以在开发者控制台应用程序的共享与令牌(Sharing & tokens)部分，使用OAuth2客户端(OAuth2 client)角色上下文对每个客户端进行OAuth客户端管理。例如，您可以配置一个自定义角色，仅授予轮换第三方应用程序客户端密钥(Rotate third-party application client secret)（multipass:rotate-client-secret）操作，并将其授予那些只应具有为特定应用程序轮换客户端密钥权限的用户。

在编辑应用程序时，使用共享与令牌(Sharing & tokens)部分的管理OAuth客户端(Manage OAuth client)选项卡，与组织、用户和组共享客户端。

:::callout{theme="neutral"} 关联的OAuth客户端权限未来可能会与应用程序权限合并。 :::

创建应用程序

要创建新应用程序，您需要具备：

• 对所选文件夹的创建应用程序(Create application)（third-party-application:create-application）操作权限，默认通过Owner或Editor角色授予。
• 对所选组织的创建第三方应用程序(Create third-party applications)工作流程权限，通常通过控制面板中的第三方应用程序管理员(Third-party application administrator)角色授予，如上所述。

网站托管

• 要查看托管在Foundry上的网站，您必须拥有开发者控制台应用程序的查看应用程序网站(View application website)（third-party-application:view-application-website）操作权限，默认通过Viewer角色授予。如果您希望用户能够查看网站但无法访问开发者控制台中的应用程序配置，您可以创建一个仅授予此操作的自定义项目角色。

• 要在Foundry上部署网站，您必须拥有开发者控制台应用程序的部署应用程序网站(Deploy application website)（third-party-application:deploy-application-website）操作权限，默认通过Editor角色授予。

• 拥有信息安全官(Information Security Officer)角色的Foundry用户可以批准或拒绝域名创建请求。

了解更多关于在Foundry上托管OSDK应用程序的信息。

应用程序权限

开发者控制台支持两种类型的应用程序：

• 面向客户端(Client-facing)： 前端服务，包括Web、桌面或移动应用程序。这些应用程序不得用于存储客户端凭据。
• 后端服务(Backend service)： 用于支持后端工作流程的应用程序，例如应用程序服务或守护进程。这些应用程序可用于安全地存储客户端凭据。

同一个应用程序可以同时包含面向客户端和后端类型。您创建的应用程序类型将决定可以使用哪种权限类型和OAuth工作流程，如下所述。

权限类型

创建应用程序时，您必须选择用于访问应用程序数据的权限类型。有两种权限类型可用：

• 用户权限(User permissions)： 用户的权限将决定他们可以读取和写入Foundry本体论(Ontology)的内容。此权限类型将使用授权码授权(Authorization code grant) OAuth工作流程。
• 应用程序权限(Application permissions)： 您的应用程序将使用生成的服务用户(service user)来获取权限，而不是应用用户权限。此权限类型将使用客户端凭据授权(Client credentials grant) OAuth工作流程。

:::callout{theme="warning"} 面向客户端的应用程序必须使用用户权限选项和授权码授权(Authorization code grant) OAuth工作流程。 :::

示例

假设您正在构建一个显示车辆数据的应用程序。

如果您希望用户只能查看他们有权访问的汽车(Cars)，请选择应用用户权限(User permissions)。如果您希望用户能够查看所有自行车(Bikes)，无论用户权限如何，请选择应用应用程序权限(Application permissions)，以使用生成的服务用户为应用程序授予单独的权限。

如果您希望用户查看他们有权访问的所有汽车(Cars)以及所有自行车(Bikes)，请选择同时使用两种权限选项。

资源访问限制

当您向应用程序的SDK添加资源时，这些资源及其依赖项将自动添加到应用程序的资源访问限制中。虽然用户必须拥有相关资源的权限，但资源访问限制确保用户只能通过给定的OAuth令牌访问为此应用程序批准的资源。

例如，当向SDK配置添加新的对象类型、链接类型、操作类型或函数时，任何所需的基础数据集或相关资源都将被添加到资源访问限制中。

为了使您的应用程序正常运行，您可能需要在依赖项发生变化时或删除资源时手动管理这些限制。

当依赖项发生变化时

如果应用程序SDK中资源所需的依赖项在添加后发生变化，您应该更新应用程序的资源访问限制以包含更改后的依赖项。您可以通过开发者控制台执行此操作，您可以在其中查看应用程序限制是否过时的警告以及纠正它们的引导式工作流程。例如，如果为已包含在应用程序SDK中的对象类型配置了新的支持数据集，则可能需要执行此操作。

检测到过时依赖项时，应用程序SDK页面上显示的示例警告。

过时依赖项的示例纠正工作流程，此处显示对象类型缺少数据集。

当删除资源时

如果您创建了删除先前包含资源的新版本应用程序SDK，如果这些资源立即从资源访问限制中删除，当前版本的应用程序使用将会中断。为防止这种情况发生，您必须从SDK中删除先前包含的资源，但将这些资源保留在资源访问限制中，直到您将所有客户端升级到新版本的应用程序，之后再将先前包含的资源从限制中删除才是安全的。

当您从SDK中删除资源时，开发者控制台应用程序将显示一个警告，确认您是否也希望将它们从限制中删除或保留它们。您可以稍后从OAuth与限制(OAuth & restrictions)页面清理旧资源。

从应用程序SDK页面删除资源时显示的示例警告。

资源访问限制中存在的来自先前SDK版本的旧资源的示例清理工作流程。

迁移到Compass管理的用户权限

:::callout{theme="warning"} 截至2026年2月，Compass管理的用户权限处于测试版(Beta)开发阶段。如果您的注册环境未启用此功能，您可以参考下面的旧版用户权限部分。随着Compass管理的用户权限逐步向正式发布(General Availability)推进，您应参考下面的迁移步骤迁移到Compass管理的用户权限。 :::

用户权限 [旧版]

与应用程序继承项目权限不同，开发者控制台用户会自动被设为他们创建的应用程序的所有者(Owner)。应用程序所有者必须随后与其他开发者共享应用程序，并从其应用程序的共享与令牌(Sharing & tokens)部分向给定用户授予权限。

您可以在给定应用程序的概览(Overview)部分的危险区域(Danger zone)面板中删除开发者控制台应用程序。与Compass资源的回收站工作流程不同，已删除的应用程序无法恢复。

请按照下面的迁移步骤操作，以确保您的开发者控制台应用程序由Compass管理。

迁移步骤

需要将旧版应用程序迁移到Compass(Migrate legacy application to Compass)（third-party-application:migrate-application-to-compass）操作权限才能迁移应用程序，该权限默认通过所有者(Owner)角色授予。

1. 打开您的应用程序并选择将应用程序迁移到项目(Migrate application to project)。

1. 按照迁移到Compass资源(Migration to Compass resource)弹出窗口中的说明选择位置。

1. 查看权限更改并选择提交(Submit)以确认。

迁移后，您的应用程序将出现在所选位置。您现在可以对应用程序执行与任何其他Compass资源相同的操作，例如移动、共享和放入回收站(moving, sharing, and trashing)。

网站查看者权限

以前，您可以使用应用程序的共享与令牌(Sharing & tokens)部分授予用户查看托管网站的权限，但不能查看应用程序的配置。

虽然对于Compass管理的应用程序，此功能默认不再可用，但您可以创建自定义项目角色以维护单独的查看权限。为防止破坏现有工作流程，请在迁移前在项目或文件夹上分配此角色。这确保所需的用户组可以访问网站，但不能在开发者控制台中查看应用程序的配置。

Marketplace应用程序

通过Marketplace部署的开发者控制台应用程序以前并非创建在其他安装资源相同的位置。随着迁移到Compass管理的用户权限，通过Marketplace安装的新应用程序也将在您提供的位置创建。

迁移来自Marketplace产品的打包应用程序不会自动迁移其先前部署的安装。每个安装也必须使用迁移步骤独立迁移。如果安装被锁定，系统可能会提示您先解锁，以便您可以将应用程序移动到该位置。