Tagged as Security because the Gitlab doc on Github has a security notice about the Github integration being vulnerable to covert redirect attacks using a subdomain (ie. an attacker being able to issue browser redirects from a some-subdomain.gitlab.wikimedia.org page can send to user to the login/authorization page at Github and intercept the resulting access token). That does not sound like a serious issue to me but probably someone from Security should evaluate it if we decide to support Github logins.

I'm not sure if I can say persuasively why this sounds like a huge can of worms to me, but at first glance it really does. Tagging for better visibility.

Wikimedia Gitlab already integrates into an SSO system, and you can't have two SSO systems (not without serious self-harm, anyway) so we'd want to use the non-SSO approach.

What is the expected benefit with this constraint in place? The workflow for a brand new contributor using this would look something like:

1. Click "sign in" at https://gitlab.wikimedia.org/
2. Be redirected to https://idp.wikimedia.org/
3. Click "Need to create a Wikimedia developer account?"
4. Read https://wikitech.wikimedia.org/wiki/Help:Create_a_Wikimedia_developer_account
5. Decide to create a SUL account via https://www.mediawiki.org/w/index.php?title=Special:CreateAccount
6. Create a Developer account via https://toolsadmin.wikimedia.org/ or https://wikitech.wikimedia.org/
7. Remember that they really wanted to login at https://gitlab.wikimedia.org/
8. Go back to https://gitlab.wikimedia.org/
9. Click "sign in"
10. Be redirected to https://idp.wikimedia.org/
11. Authenticate with their Developer account username and password
12. Be redirected to https://gitlab.wikimedia.org/explore
13. Find the link to https://gitlab.wikimedia.org/-/profile
14. Realize that the "Account" sub-navigation includes a button to connect their GitHub account to gitlab.wikimedia.org
15. Make that association by approving the OAuth application integration at GitHub
16. Profit??

What utility did the hypothetical contributor gain if they passed the gauntlet of doing all of this? Presumably something that makes implementing T325106: Import Merge Requests from GitHub read-only mirrored repos into GitLab more exciting, but at the moment I'm not sure what. They now have a Developer account that has been connected to our GitLab so contributing drive-by patches via non-standard GitHub pull requests is no longer a benefit for them. Or is it somehow that I'm missing?

Toolsadmin should redirect back to the source of registration after step 7, but that's a separate story.

Yeah, it's more or less as you say, except if the user has the primary email address in Github and Gitlab, they can just click on the "login with Github" button in step 9 and skip the rest. But the main benefit would be the ability to correlate accounts, which is useful for security reasons (e.g. ensuring the Github user with the same nick is really the same user when responding to some request on Github - many MediaWiki extensions are developed on Github), statistics, looking up users' contributions, probably anti-abuse features (treat the user as somewhat trusted if they have some amount of not very recent Github contributions - the CI allowlist will go away with the migration but there might be other use cases where a trusted status is useful), and yes, automation like importing pull requests from Github.

Strictly from the contributor's POV it's 1) easier login (if they are logged into Github most of the time, but not logged into Wikimedia IDP most of the time) and 2) indicating your contributions elsewhere (ie. basically gamification - the "I added one more badge to my profile" feeling).

Also, I'd hope that one day signup happens via Apereo and not Toolsadmin / Wikitech and then the user can really get from "I have no developer account and click on the login-with-github button" to "I am at gitlab.wikimedia.org, logged in with my account connected" in one single seamless signup flow.

In T325235#8475274, @Tgr wrote:

Also, I'd hope that one day signup happens via Apereo and not Toolsadmin / Wikitech and then the user can really get from "I have no developer account and click on the login-with-github button" to "I am at gitlab.wikimedia.org, logged in with my account connected" in one single seamless signup flow.

T319405: Create an IDM for Wikimedia developer accounts is the active project that will replace Wikitech as a Developer account creation source. Striker will be updated to integrate with that system once it exists.

In T325235#8475268, @Tgr wrote:

But the main benefit would be the ability to correlate accounts, which is useful for security reasons (e.g. ensuring the Github user with the same nick is really the same user when responding to some request on Github - many MediaWiki extensions are developed on Github), statistics, looking up users' contributions, probably anti-abuse features (treat the user as somewhat trusted if they have some amount of not very recent Github contributions - the CI allowlist will go away with the migration but there might be other use cases where a trusted status is useful), and yes, automation like importing pull requests from Github.

That really seems like a use case for the IDM to fulfill rather than trying to use the opaque internals of GitLab to store correlated data that as you say we would like to reuse for other workflows.

We had discussions for Phabricator about supporting GitHub has a third party authentication:

• T16: Support only WMF SUL and LDAP as authentication mechanisms (no purely local logins, no third party authentications)
• T200: Decide on a plan to offer GitHub as authentication provider
• T169007: Support Google and Github accounts for authenticating in Phab to ease volunteer contribution sign up

We had one about allowing Facebook login on Wikimedia wikis T61631: Enable Facebook login on Wikimedia wikis.

A RfC to use GitHub login for mediawiki.org T215046: RfC: Use Github login for mediawiki.org

And another one still open to use Google account for Wiki authentication T138695: Allow registration and login with a Google account.

If the issue is a new comer has a long jounrney to create an account and participate (see tasks at T325235) I guess we can work on making the experience easier and more pleasant? I am inclined to decline this request to support GitHub or any other third party in order to authenticate to our Gitlab.