Permissions

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

User permissions

Users of the Developer Console are automatically set as the Owner of the applications they create. The application owner can share the application with other developers and grant permissions to given users.

A user of the application could have one of the following roles:

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

Create applications

A user must have the Third-party application administrator role to create a new application in the Developer Console. Once an application is created, the user can then share the application with other developers and grant them Editor permissions, as explained below.

Website hosting

With website hosting, you can host and serve the files of your application on Foundry. For more detail, view the Deploy an Ontology SDK application on Foundry (Beta) documentation.

• To deploy a website on Foundry, you must have Editor permission on the specific Developer Console application. Refer to the user permissions documentation for more information.

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

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.

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 scope

As you add resources to your application's SDK, those resources and their dependents will be automatically added to the application's resource access scope. While users must have relevant permissions for the resources, the resource access scope ensures 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 scope.

For your application to function correctly, you may need to manually manage the scope 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 scope to include the changed dependencies. You can do this via the Developer Console where you can view a warning if an application's scope is outdated and a guided workflow for correcting it. 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 scope. To prevent this from happening, you must remove previously-included resources from the SDK but keep these resources in the resource access scope 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 scope 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 scope or keep them in. You can clean up old resources later from the OAuth & Scopes 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 scope from previous SDK versions.