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."
Related
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.
I'm not that familiar with Github Actions and how their runners work but my Devops team are adamant that we cannot run any github actions that require runners because the runners are public and it puts our code at risk of being accessed by 3rd parties.
I know there is an option to use hosted runners, but we're not there yet.
Looking for any advice/references that devs with experience can provide me to dispel these rumours
As per the articles Link1 and Link2, GitHub public hosted machines are more secured than self-hosting machines. (At least the articles claim so)
In my experience, big organizations that are very particular about security always go for self-hosting machines which require separate teams to maintain.
The choice should be completely based on what type of application you use and how well you are managing the secure details within the repo.
There are several ways for GitHub-hosted Actions runners to connect to resources on your private network, as described in this 2022 June GitHub blog post:
Use the GitHub Actions OpenID Connect (OIDC) token to authenticate through an API gateway (we open sourced a reference implementation as an example, but do note that it requires customization for your use case and is not ready-to-run as-is).
You would run the API gateway on your infrastructure, but as it is stateless, it can scale quite well for high-bandwidth use cases.
:
You can use WireGuard to create a temporary overlay network between the GitHub Actions runner and your private network.
You can use a commercial solution for an overlay network, like Tailscale.
Based on WireGuard, it has similar advantages and disadvantages, except that as a commercial product, it’s even easier to set up and includes NAT traversal.
Please note that it might require a paid plan for higher data volumes.
Currently, the company I work for maintains several popular vscode extensions. However, after the VSCode Marketplace publisher token generation has been moved to Azure, we've dont have any way to access the organization which corresponds to the Marketplace publisher in order to generate new publishing tokens. We have no idea who has access to the Azure account within the company.
How can we gain access to the organization page?
Send an email to: Visual Studio Marketplace. (VSMarketplace#microsoft.com)
They can help you with the available options.
We would like to integrate Gitlab with Okta, any advice on how to get started?
I met this question a few times while trying to get this working, posted the results on the following GitLab issue https://gitlab.com/gitlab-org/gitlab-ce/issues/14122#note_17669455
Yes, with GitLab 13.0 (May 2020), but only for Premium and more (so not free), and only for gitlab.com (not self-managed)
Okta SCIM Integration Application for GitLab.com
We now offer an Okta SCIM integration application for Gitlab.com groups!
When Okta SCIM is provisioned for a GitLab group, membership of that group is synchronized between GitLab and Okta. This reduces group administrator time spent to onboard and offboard users.
See documentation and issue.
Update 2023: GitLab 15.8 (January 2023) add support for self-managed GitLab instances as well! (still premium+ only).
SCIM support for self-managed GitLab
Self-managed GitLab now supports the open standard System for Cross-domain Identity Management (SCIM), which allows you to automatically:
Create users.
Remove users by deactivating their SCIM identities.
Previously, this was only available for GitLab.com.
SCIM enables GitLab administrators to completely automate their user lifecycle management.
See Documentation and Issue.
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.