🚀 copilot: Support custom authentication resolution

[ScottGuymer]

Plugin Name

copilot-backend

🔖 Feature description

The plugin currently relies on the built in integrations config for resolving the credentials used to speak to the GitHub copilot metrics API. This metrics API is on the enterprise level.

We currently use an org level GH app to authenticate against GitHub from our instance which does not have the ability to authenticate against the enterprise level APIS.

We need a way of being able to inject or configure a different way of authenticating against the enterprise level api.

🎤 Context

We use a GitHub app from the integration config for our authentication against github.

It is not possible to use these app creds to speak to the enterprise level copilot API.

✌️ Possible Implementation

I can think of two things.

• Update the current implementation to somehow use the enterprise id when selecting the correct integration config
• Exposing an extension point for the plugin that allows consumers to provide their own implementation of a credential resolver so that we can use another way of getting the enterprise level PAT

👀 Have you spent some time to check if this feature request has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

Are you willing to submit PR?

Yes I am willing to submit a PR!

[ScottGuymer]

CC @esw-afabiano

[esw-afabiano]

Hey @ScottGuymer,

Thank you for bringing this issue to our attention.

From what I understand, you have a token at the organization-level, but Copilot requires a token for the enterprise-level, correct? As it stands, this isn't possible because we are reusing the current GitHub token.

We can revisit the possibility of making the token a setting inside the copilot config again. What do you think about this, @awanlin? Do you have any suggestions on what could be done?

I would also like to point out that currently the plugin does not support integration at the organization-level. Even if your token has the necessary privileges, Copilot users need to be within an enterprise for authentication with the enterprise-level metrics API to function properly.

I wanted to let you know that I'm working on a Pull Request to add support for organization-level integration as well. I've completed most of the implementation, but testing has been a bit more complex since we don't have all the necessary resources set up within our organization at the moment.

If I haven't fully understood your requirements, could you please provide more details? This will help ensure that the solution accurately addresses your needs.

Thank you for your patience and for your interest in improving the plugin. Please feel free to reach out if you have any further questions or need assistance. You're also welcome to follow the progress of the Pull Request or contribute with suggestions.

[ScottGuymer]

We use a GitHub app (not a PAT token) in the integrations config of backstage for authentication into our GitHub org.

Config looks something like this

integrations:
  github:
    - host: github.com
      apps:
        - appId: ${AUTH_GITHUB_APP_ID}
          allowedInstallationOwners:
            - 'my-org'
          clientId: ${AUTH_GITHUB_CLIENT_ID}
          clientSecret: ${AUTH_GITHUB_CLIENT_SECRET}
          webhookSecret: not_required
          privateKey: ${AUTH_GITHUB_PRIVATE_KEY}

This GH app is an org level app that has access to a single org (not a public app). It does not have access to any enterprise level APIs.

My understanding is that currently GitHub apps do not work at all for enterprise level APIS and the only way to access these is with PAT tokens.

We want to use the enterprise level API to get the copilot data so do not need any org level copilot data.

Therefore we need some other way of resolving the PAT token required to access the enterprise copilot API.

My suggestion was for this plugin to provide an extension point.

This would be done by defining (and exporting) an interface for a credentials resolution function that would return a GithubInfo type. We could then refactor your implementation in getGithubInfo to match this interface and act as the default implementation.

This would leave users of this plugin free to implement their implementation of the credentials resolver to get enterprise credentials (either from config or even some other location) and patch them into your plugin at the point it is instantiated in their instance.

---

The other option I could think of is refactoring the DefaultGithubCredentialsProvider to be "enterprise aware" and be able to resolve different credentials when you supply it a GitHub host with enterprise info in the uRL. URLs like https://github.com/enterprises/royal-philips.

Unless this functionality already exists? which i dont think it does as the enterprise value is not used in the credentials resolution here https://github.com/backstage/community-plugins/blob/main/workspaces/copilot/plugins/copilot-backend/src/utils/GithubUtils.ts#L36

[esw-afabiano]

Heyy

I got it now. The issue with DefaultGithubCredentialsProvider may need to be raised with the Backstage maintainers. Perhaps the most viable solution is to implement this refactoring within the copilot-backend plugin itself.

[ScottGuymer]

I made a start at the PR for this here

#1260

[ScottGuymer]

Find me on the backstage discord. Id love to chat about this plugin and how i can help improve it.

I also created #1259