Admin configuration for available ORT plugins

[mnonnenmacher]

Currently, the used ORT plugins like package managers, advisors, scanners, or package curation providers can be freely configured via the API when creating an ORT run. This is problematic because:

• Some tool configurations support setting arbitrary URLs which can be a security issue.
• The server admins have no control over which user can use which tools.

The current solution to this issue is the parameter validation script executed by the config worker. This script allows to modify any incoming ORT run requests to set default values or replace or remove values. While this approach is very flexible it has also some downsides:

• Writing and maintaining the Kotlin script can be difficult for new adopters and requires implementing tests to ensure that it behaves correctly.
• For the user it is intransparent how the script operates: Without additional documentation the only way to figure out how requests are modified is try and error.
• It is not possible to implement a UI to configure the available tools.
• It is not possible to implement an API endpoint that provides information about how requests are modified.

To improve the situation the API should be changed to allow the server admin to configure the available tools, and to configure which organizations have access to which tools. This would allow to add API endpoints to requests the available tools and also to implement an admin UI for the configuration.

With the example of advisors, this is how it could work:

Currently, the advisors can freely be configured via the advisors and config properties of the AdvisorJobConfiguration. The config property exposes ORT's PluginConfiguration object which can for example allow to configure the URL of an advisor.

Instead, let the admin configure a list of available pre-configured advisors that the users can choose from:

• The available advisor configurations are stored in the database.
• The available advisor configurations can be requested via the API and the user can provide the identifier of the configuration in the AdvisorJobConfiguration (this endpoint could be used by the UI as well).
• The admins could configure which organizations have access to which advisor.

[sschuberth]

Just sharing my thoughts how this should work from a UI perspective: An admin of an ORT server installation should be able to see all e.g. ORT advisor plugins that are available on the classpath in a list, and from this list the admin should be able to select which of these advisors are made available for each organization. The API should support this UI requirement.

[mnonnenmacher]

admin should be able to select which of these advisors are made available for each organization.

In addition to that it should also be possible to configure the plugin options and to have multiple different plugin configurations for the same plugin. This would be required, for example, to configure different FossId instances for different organizations.

An exception to that should be the package managers, here it should still be possible for users to configure them via the .ort.yml file (and probably this is good enough and there is no need to duplicate those configuration options in the API like it is currently the case).