I am building a web application where users have to provide my web application access to their repositories in GitHub| Bit bucket| Git Lab | any other code hosting platform.
I have implemented it through OAuth2 for which I had to create client applications on all platforms separately.
Initially it was scoped only to GitHub | Bit Bucket but now I want my web application to support all other major platforms as well.
So my current implementation requires me to create client applications for all other plat platforms which is a hectic because We want to give support for On-Premise version control system as well.
Is there a secure and generic way to authorize to version control system ?
One solution is that user directly provide their Personal Access Tokens (Encrypted) to my web application so that my application can save these PAT and use them to pull the repositories in future.
But I wonder if this is a secure enough or a standard method. If not then what might be the appropriate solution to this problem.
You might need to use an Oauth2 provider like:
dexidp/dex, an identity service that uses OpenID Connect to drive authentication for other apps.
Dex acts as a portal to other identity providers through "connectors", which do support your targets
or casdoor, an Identity and Access Management (IAM) / Single-Sign-On (SSO) platform with web UI supporting OAuth 2.0, including some of your targets.
Oauth2 is not the only option, as illustrated by SmartGit
After some reflection I realized that I actually haven’t had authentication problems with SmartGit and Azure DevOps for quite a while, so I spent some time experimenting to figure out just how SmartGit is authenticating to my repos in Azure DevOps.
I ultimately determined that it uses Personal Access Tokens via the Git Credential Manager.
So explicit support of PATs by SmartGit probably isn’t a critical feature after all. When you install Git (on Windows at least), you have the option to install the Git Credential Manager as well.
As long as you do that you should have smooth sailing.
Related
Seeking input from anyone who has done this before.
We need to create additional organizations in GitHub that will be accessible to different groups of users so we moved to the Enterprise Cloud implementation. Our single Org will be moved into the Enterprise to absorb the seats into our Enterprise licenses.
We are using SAML SSO on our current org. I would like to setup a separate IdP definition for the Enterprise SSO configuration to start with and migrate the org users to the enterprise at a later time. Will this work as described?
I realize there may be some action innersource issues for private repos. But I think those just need to be changed to Internal.
If you have performed a similar migration, did you run into any unexpected issues? Do you have any tips to avoid any nasty hiccups?
The answer from their support groups is no, this will not work.
"configuring SSO at the Enterprise will overwrite SSO for all organizations under it."
What is the difference between a GitHub App and the REST API for GitHub? Why would you need a GitHub App if you can just use the REST API, without setting any environment up?
The REST API should just be a collection of endpoints that accept a POST along with access tokens. But the GitHub App requires cloning an entire repo written in Ruby, that has nothing to do with my app.
I am not looking for users to integrate with my repo, I want them to be able to connect their own repo to the application.
But the GitHub App requires cloning an entire repo written in Ruby, that has nothing to do with my app.
I don't believe this is true.
GitHub Apps make the process of integrating 3rd party tools into your GitHub repositories smoother.
GitHub Apps are installed by organizations and granted access to specific repositories via GitHub. For example, CodeClimate is a tool which performs checks on pull requests. Rather than granting them OAuth access to my repositories, I can install the CodeClimate GitHub App on my organization and configure which repositories they have access to. I can see all the apps installed and what their permissions are.
Note that "installing" a GitHub App does not install any code. "Installing" gives the app permissions for the service to access your organization and repos. A GitHub App is a wrapper around an existing service.
If you want users to connect their repos to your application, consider a GitHub App.
This is covered in About apps.
An OAuth App acts as a GitHub user, whereas a GitHub App uses its own identity when installed on an organization or on repositories within an organization.
GitHub Apps are the officially recommended way to integrate with GitHub because they offer much more granular permissions to access data, but GitHub supports both OAuth Apps and GitHub Apps.
GitHub Apps are first-class actors within GitHub. A GitHub App acts on its own behalf, taking actions via the API directly using its own identity, which means you don't need to maintain a bot or service account as a separate user.
GitHub Apps can be installed directly on organizations and user accounts and granted access to specific repositories. They come with built-in webhooks and narrow, specific permissions. When you set up your GitHub App, you can select the repositories you want it to access. For example, you can set up an app called MyGitHub that writes issues in the octocat repository and only the octocat repository. To install a GitHub App, you must be an organization owner or have admin permissions in a repository.
GitHub Apps are applications that need to be hosted somewhere. For step-by-step instructions that cover servers and hosting, see "Building Your First GitHub App."
Differences between GitHub Apps and OAuth Apps has a complete breakdown.
i am interested in building a github app. reading through github Setting up your development environment to create a GitHub App documentation it explains that a github app is based on a http server which will handle webhooks.
yet, on every github app i installed, the app\installation did not require anything that involves hosting and/or creation of http server in order to deploy the app to my github accout.
for such github apps, which are installed directly through the github marketplace (you can take probot stale and rennovate as examples for such apps)
where do these application run? (e.g.; does github deploys the app on a dedicate (virtual) server?).
what are the resources limitations for such apps (amount of memory, cpu, etc.?)
how can the github app logs be accessed by the github account owner who installed such app?
links for reference and an answer will be great.
GitHub App is just another app that you create. GitHub apps are treated as first-class citizens when it comes to integrating with GitHub. One can use Nodejs , Ruby, etc to build the App. Once the app is ready it can be hosted on a Server just like any other server hosted apps. You register your app on GitHub by providing relevant details.
So, coming to your questions.
The Apps can run on any hosting service of your choice. It can be a Windows Server, Heroku, etc.
I believe it is only limited by the resource of your server or the hosting service provider that you chose. However you might be ineterset in erading more about the Rate Limit More on Rate limits here.
GitHub app logs are something which only the developer will be able to see. To the end user ,i.e. the repo owner who installed the GitHUb app on his repos, all that will be available are the checks , statuses and any other details that the developer of app decided to display.
A very handy guide on Deployment and other details : Probot Documentation. This documentation is great if you are planning to use the probot framework for developing your github apps, but most of the instructions still stand true in case you decide to pick up a different tech stack.
The most important thing to realise about a (so-called?) Github App is that the App itself does not run anywhere - or at least that is what I would argue. Basically Github Apps are two linked mechanisms, both a bit of infrastructure. The first of these mechanisms is access control, essentially replacing use of user PATs - you can give relatively fine grained access to repos that the App is installed in, rather than just giving access to all repos the user can access. The second mechanism is that of webhooks - generating events as requested.
What Github Apps do not directly provide is the bit between this - handling the webhooks and generating API calls using the App for access. Basically you are on your own and need to do it yourself. The plus, #asif-kamran-malick mentioned, is that you have freedom to implement it how you see fit.
One alternative possibility is that the App itself, rather than setting to handle ongoing Webhooks, runs on installation and looks to add Actions into the repo. Never done it, but some of the github examples seem to work this way. Of course, Actions are run within Github environments and are potentially subject to resource limits. Apart from this though, Actions are a completely separate "beast" and should not be confused.
I have a Github App set up using their v3 API. I am successfully authenticating and I can create and modify repositories. I'm trying to also attach a deploy key to a newly created repository. However, I'm getting 403: Resource not accessible by integration -- this is regardless of whether I try to read or write the keys. The app is installed on the organization, and the repository is also owned by that same org.
The api documentation gives routes for managing deploy keys: https://developer.github.com/v3/repos/keys/#add-a-new-deploy-key
But the permissions list doesn't mention deploy keys at all: https://developer.github.com/v3/apps/permissions/#permission-on-administration
I have turned on Read & Write access for Repository Administration, Repository Contents, and Repository Projects in the permissions for the app, but I'm still getting this access error.
That endpoint hasn't been enabled for GitHub Apps yet -- you can only use it with OAuth tokens currently (or Basic Auth).
I recommend requesting that this be added for GitHub Apps over on the Platform forum for Apps:
https://platform.github.community/c/integrations
That's the best place to ask questions and provide feedback about GitHub Apps (GitHub staff monitors that forum and answers questions).
I can add deploy keys with "Read and write access to administration" permission. (as of Jan 17, 2023)
Using Visual Studio Team Services you have to enable Alternative Credentials in order to be able to connect to TFS Git Repo. using Eclipse or any other Git Client,
My problem is i want to connect to TFS on-premises Git repo. using Eclipse but there is no way to enable Alternative Credentials, any way to enable Alternative Credentials to be able to do that ? or can i do it other way?
TFS15 now supports Personal Access Tokens and SSH access, so your question isit's not entirely off the mark. There are scenario's where connecting using NTLM or kerberos security is not possible, but as #edward-thomson pointed out, the alternate credential is still linked to a domain account and should not be handed out to 3rd parties.
Instead users will need to be added to Active Directory, or a trust relation (or Federation) needs to be in place so the user is able to join using it's own orgs AD account.
If you're using Git, you could opt to also store the repository on Visual Studio Team Services and push/pull between that and your own TFS server. That way you can give 3rd parties access using their MSA or AAD account, while keeping the main repository secured using AD accounts only. Given the fact that Git is able to transfer data and history with ease, that's not an entirely weird scenario. It fits with the whole Distributed nature of Git quite well.