🚀 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?

• [X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• [X] 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

https://github.com/backstage/community-plugins/pull/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

[awanlin]

Hi @ScottGuymer, this might also be on me. When I reviewed the plugin I suggested using the DefaultGithubCredentialsProvider assuming that the APIs would be available like any other within GitHub. During my reviews I tend to focus on making sure we take advantage of built in framework features of Backstage so that plugin owners have less to maintain and their plugins work more like others which means Adopters have a smooth experience using them.

Now in this case the extension point makes sense for more advanced Adopters but for most doing this is going to be a high barrier to entry and I feel that some built in support for this would be good as well. The plugin should be able to be smart enough to say - this is an Enterprise API so going to use the PAT vs this is an Org API so going to get the token from DefaultGithubCredentialsProvider. As I can easily see this plugin becoming popular I think a low code approach makes sense. The perfect approach would be support upstream but I think for now having it in the plugin is fine and you can itterate on it more quickly this way.

[esw-afabiano]

Hey @awanlin,

I think initially, to accommodate all scenarios and ensure that everyone can use it without significant complications, we could revert to using the token directly in the copilot context. We can open an issue to revisit this implementation for other scenarios at a later time. What do you all think?

cc: @ScottGuymer

[Djiit]

@esw-afabiano that would be awesome, as it would unlock this plugin's usage for many users.

[ScottGuymer]

Ok I will refactor my PR to just use plugin level config.

The current version only uses enterprise APIs, i am unsure about the auth required in the updates made in #1261

Do we think it would be good to keep the extension point and simply provide a default implementation that gets its from config like

copilot:
  token: *********

[ScottGuymer]

I have made these changes in the PR.

There is now a default config for using the token from the copilot section in the config.

There is an optional config for using the integrations config available via an extension point configuration.

And then any other option you are willing to write via an extension point.

[vinzscam]

Closed by #1928