feat: Allow default Backstage auth policy on plugin route

[jkueh]

Description

This is a recreation of PagerDuty/backstage-plugin-backend#114.

Corresponding documentation update: PagerDuty/backstage-plugin-docs#14

Currently, any user that is able to access a Backstage instance that has the PagerDuty plugin installed can make proxied calls to the PagerDuty API without needing a user session in Backstage, e.g.

curl "https://${BACKSTAGE_HOST}/api/pagerduty/services"

The above will return a list of all the services in the account, and presumably can make other proxied API calls to the rest of the PagerDuty API, subject to the permissions of the API token available in Backstage.

This PR disables the unauthenticated policy by default. Backstage's documentation refers to the unauthenticated behaviour as dangerous.

I've tested this in a local instance of Backstage, and can confirm I get an HTTP 401 when attempting to run the same curl command as above without a valid Authorization: Bearer ... header.

Affected plugin

• backstage-plugin
• backstage-plugin-backend
• backstage-plugin-scaffolder-actions
• backstage-plugin-entity-processor

Type of change

• New feature (non-breaking change which adds functionality)
• Fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• I have performed a self-review of this change
• Changes have been tested
• Changes are documented (doc: Add section on authorization on the Backstage Backend API backstage-plugin-docs#14)
• Changes generate no new warnings
• PR title follows conventional commit semantics

If this is a breaking change 👇

• I have documented the migration process
• I have implemented necessary warnings (if it can live side by side)

Acknowledgement

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[jhfgloria]

Hello @jkueh! Thanks for flagging this! I think we should flip the enablement logic, making it unaccessible by default and having a property to make it accessible without token. That would make the plugin more secure by default and less secure on demand. In that case we would release a new minor version to flag the change. Could I ask you 2 things too? Since we changed the plugins into a monorepo, new contributions internal and external should be backed by a release note, which can be easily generated by running yarn changeset. Could you create a minor version for backstage-plugin-backend in this pull request? Also, could you change the base branch from main to next? Thank you again @jkueh!

[jkueh]

Hi @jhfgloria!

Not a problem, will do those shortly.

My initial thinking was that if we're doing a minor release, we probably shouldn't be breaking any existing implementations that rely on access to this plugin being unauthenticated.

That being said, happy to switch it around as part of a minor release if this is more bug-fix territory :)

[jkueh]

@jhfgloria All done, I think! Let me know if there's anything I've missed :)

[jhfgloria]

Looks good to me! Thank you so much for your contribution @jkueh!

[jkueh]

No problem, thanks @jhfgloria!