EPIC Goal

Provide guardrails to ensure that a user knowingly overrides a core service from a dynamic plugin and understands the implications.

Background/Feature Origin

Why is this important?

Having access to customize the root http router is a handy feature to tackle various cross-cutting issues. However, given that this allows access to the underlying Express app, a plugin that installs one of these also has the ability to modify or even redirect requests intended for other backend plugins, which opens the door to potential security problems.

We may need to explicitly define the defaults for important core services like httpRootRouter, auth or discovery, as the ability to override the configuration for each of these from a dynamic plugin can potentially enable different attack vectors.

User Scenarios

• as a user I would like to know if a plugin has installed a backend feature that customizes a core service

Acceptance Criteria

• There should be at the very least a log statement informing the user that a core service has been customized from a dynamic plugin
• Ideally such a customization could also be written to the audit logging facility.
• Ideally the ability to customize a core service from a dynamic plugin should require the user's approval, perhaps a configuration entry to allow modifications to services with id=core.* or with a service ref of scope "root"