Github Apps Auth? about roadie-backstage-plugins HOT 22 CLOSED

I used the Github App for OAuth successfully. Thanks for the suggestion!

from roadie-backstage-plugins.

https://app.clubhouse.io/larder/story/3533

from roadie-backstage-plugins.

@martina-if not sure if that link is for internal reference only, but wanted to let you know i'm unable to see that, if that's something you're expecting me to be able to see

from roadie-backstage-plugins.

@athal7 Thanks, this link is for internal tracking :)

@punkle is this something you can help with?

from roadie-backstage-plugins.

@athal7 Would you prefer that the API request for the github insights and pull requests get passed through a proxy in the backend, and the GitHub App installation token be used to request the details from the API? If that is right can indicate why this is preferred over using the OAuth token in the frontend?

If this is the case, how would github privileges be honored within backstage?

from roadie-backstage-plugins.

@punkle yes exactly through a proxy. Reason being we have more than one GitHub organization, and the OAuth app is only installed into the primary, but the GitHub Apps auth has access to the others as well.

I’m not aware of use cases where GitHub privileges should be honored in backstage for these plugins - seems they are all reading information about entities that are imported to backstage and therefore visible to the full audience. Can you clarify?

from roadie-backstage-plugins.

Yes, so the OAuth token is issued to the user in the frontend negortiated via the OAuth flow. The user has privileges associated with them in an organization and the API calls that the browser makes are authorized by GitHub based on the user accessing the resources.

A GitHub App is installed in an Organization and has a separate set of privileges associated with it. An example here is.. the Dependabot API requires admin write access. Should we expect a frontend user with only membership (i.e. not an owner) of an organization to view the dependabot issues through Backstage? Similarly with Pull requests, if the app has admin write permissions, are members able to see every pull request regardless of their membership status of an org.

I am aware that the backend already catalogs everything, however I think this is limited to the catalog-info.yaml files and the data within.

Maybe there is an established pattern for this existing in backstage already that I am unaware of.

Id love to follow this thought through, because we are currently working through this thought process in Roadie.

from roadie-backstage-plugins.

Ah that's helpful. For us, surfacing those dependabot issues to all would be beneficial, but I can imagine organizations where that's not the case.

What if you make it an option to choose per-card which auth type is used? That would then correlate to whether the request is made directly or through the proxy.

e.g. language insights & releases are less sensitive than dependabot issues, with pull requests somewhere in-between, so some organizations might want a hybrid approach.

from roadie-backstage-plugins.

I think that sounds like a reasonable suggestion and would be a good addition. I am not sure if this is something we will be able to get to in the short term, is this something you would be willing/able to contribute?

from roadie-backstage-plugins.

So from what I can tell the Github App Auth doesn't use a single token that could be easily supplied in proxy settings in the app-config.yaml, but rather uses more temporary tokens managed by the GitHub integration. This leads me to think that in order to achieve this goal, a new package would need to be created that would get installed into the backend of backstage instances (e.g. how the todo and todo-backend plugins work together).

If all of that understanding is correct, I imagine there is a decent amount of restructuring/sharing of logic and/or internal processes for creating a new package... probably challenging for someone outside your organization to successfully tackle without significant collaboration.

If I'm analyzing the situation correctly, I don't want to disrupt your priorities and am ok being patient. If I'm missing something obvious/easy to tackle, I'd be open to contributing.

from roadie-backstage-plugins.

I am unsure about it being a straight proxy that populates the request headers with an up to date installation token. Based on the concerns I mentioned around exposing private data to everyone in backstage. E.g. if dependabot is desired, the app will be enabed for full admin privileges which in theory would mean that any backstage user would be able to behave like an admin in github if they know how to use the github api directly.

This would then imply that the new Jira backend would have to expose very specific data for the frontend.

Is that also how you see it?

I should say that I am also unclear about priorities but I'll try get more clarity on that.

from roadie-backstage-plugins.

Yes good point, another reason why we would want to do a specific backend package similar to the todo plug-in to only enable certain types of data to be fetched.

from roadie-backstage-plugins.

@athal7 I was chatting with the rest of my team this morning. I think I am still not understanding exactly the case for this change. At least I was finding it hard to articulate.

So I just wanted to circle back to the case for this suggestion if that is ok.

OAuth Apps are installed by any user of GitHub. The user is given the ability to request that the OAuth app is authorized by any GitHub organization that that user is a member of. Assuming the GitHub Organization owner approves this request the tokens issued to the user in the frontend can be used to access the resources in the organization. This applies to all of the organizations that the user is part of. So that same OAuth App can be authorized by multiple organizations and the same token used for multiple organizations.

Also are you aware that the GitHub App (not Github OAuth apps) also have a client id and secret that can be used to provide OAuth to the users of the organizations in which it is installed? This allows similar API access to the OAuth users on the frontend when the GitHub app is approved.

from roadie-backstage-plugins.

Ah, it sounds like there are some features of these auth styles with which I was not familiar. I’m going to try some of the things you mentioned and get back to you with something more concrete if it doesn’t achieve the intended goal.

Thank you for your help!

from roadie-backstage-plugins.

@punkle do you know what permissions are required when using a Github App like this? Pull Requests are fetching fine, but releases are responding with a 401.

From what I can tell, the URL should be covered by the contents access, which has been granted for this app
https://docs.github.com/en/rest/reference/permissions-required-for-github-apps#permission-on-contents

from roadie-backstage-plugins.

There is a specific pull requests permission. It needs read only.

from roadie-backstage-plugins.

Pull requests are fine, it was releases that were the problem. But it seems to have resolved with a reset of the local & cookie storage for now

from roadie-backstage-plugins.

Oh sorry about that. I skim read. Which plugin uses the releases API? I would need to figure it out I think. I am not sure I have come across this issue.

from roadie-backstage-plugins.

Here are the permissions we have setup on our app.

from roadie-backstage-plugins.

ok thanks. I think I'm all set for now. sorry for the red herring

from roadie-backstage-plugins.

Were you able to fix it? Which permission did you need? Which plugin uses it? I'm very curious.

from roadie-backstage-plugins.

The contents permission was correct, I think I just had an expired auth token in my local storage that was somehow only being used for the releases api call but not the pull requests api call

from roadie-backstage-plugins.