The HERE platform provides you with control over the apps that you create and the apps to which you have been given access.
When you create an app, you have full permissions to manage the app including the ability to create credentials and manage access to the app. The app creator has read, write, manage and share permissions to the app.
Your app and associated credentials do not inherit your user permissions or your group memberships. App credentials are valid until you delete your app or delete or disable the access key.
Follow the steps below to disable or delete an app key.
When you delete or disable a key, associated processes such as pipelines cease functioning.
Follow the steps below to enable an app key.
Follow the steps below to delete an app.
Processes associated with an app such as pipelines cease functioning a maximum of 24 hours after you disable or delete this app.
Additional managers can be added by an app manager by clicking on the "Add a new manager" button in the Access and permissions tab of the app details page. This can also be done from the More menu. Users, groups, and apps can all be app managers.
New app managers are granted read, write, and manage permissions to the app. The share permission is not granted by default.
If you have share permissions, you may share your app with other users, groups, and apps as shown on the More menu. Users with share permission can also grant permissions to other users and apps. To obtain share permission, select the More drop-down list in the app's Access and permission tab.
The read, write, and share permissions are granted when an app is shared.
A powerful feature of apps is the ability for an app to create other apps. This can be enabled from the More menu on the app details page.
App managers can specify a default project for the app during or after the creation of the app. This means that requests from this app will be scoped to the specified project by default, allowing you to track usage by this app on a project level.
When creating an app from a project in the Projects Manager, the system will automatically set the default project to the project you are working in. When creating an app from the Access Manager, you can optionally select a project in the "DEFAULT ACCESS TO A PROJECT" field.
To set the default project for the app after it's been created, go to the app details page in the Access Manager, select the Edit app menu option, and select a project in the "DEFAULT ACCESS TO A PROJECT" field.
You can also set the app to only request resources in the scope of the default project by selecting the "Allow access in only default project" checkbox during or after app creation. This setting is recommended for apps using API keys because it helps secure the use of your API keys. It also allows you to track usage by project for an app using an API key.
Apps set to only request resources in the scope of the default project cannot be added to groups. This is to prevent the app from inadvertently becoming a member of other projects (via its group membership) where it won't work since it's restricted to use in another project.
If you need to use an app across multiple projects, for example to orchestrate CI/CD processes, we recommend you use OAuth tokens and set the project scope as needed when requesting the token.
Org Admins can assign roles to both users and apps. To assign a role to an app, create or select the app on the Apps tab in the platform Access Manager. Then use the More menu on the app details page to assign the required roles. As always, utilize "principle of least privilege" best practices and only assign necessary roles. Apps having the Org Admin role, for example, will have full rights to manage users, apps and resources in your Org.
Assigned app roles can be viewed on the app details page and using the platform CLI command,
olp app show <app HRN>.