gerrit-oauth-provider exist in the wild, but I don't know LDAP implications and whether it makes sense to investigate with Differential being the long-term goal...

I thought about differential. However my impression is that a total migration will still take some time. In the meanwhile, maybe we can benefit from it. Thanks.

I'm not sure it's worth the work, we don't really need non-technical users in gerrit do we?

I'd say that we don't due to the nature of gerrit. I recognize that it's mainly because of lazyness that I'm asking for this, so I don't have to type so many times a password to log in to Wikimedia, to Phabricator, to Gerrit and Wikitech. If most of the active gerrit regulars won't find it useful, I'm willing to drop the request. I'm however sorry not to have found a more appropriate place to discuss and propose this.

@bd808 has plans for eventually merging LDAP with SUL, I think.

In T147864#2706550, @Tgr wrote:

@bd808 has plans for eventually merging LDAP with SUL, I think.

There isn't a full plan with a timeline yet, but yes I'm starting work towards associating LDAP and normal Wikimedia unified accounts. When we get this fully done then it may be possible to find a way use Wikimedia OAUTH with gerrit.

I doint think this will work, I believe gerrit only supports one login system at a time unlike mediawiki which can support a lot. But I'm guessing here.

It's not a very good standard though (e.g. the registration experience we provide is pretty bad) and probably probably contributes to our dwindling volunteer numbers. Plus having passwords is always an annoyance and a slight security risk (no keylogger can steal an OAuth login button). There would be merit in using a more sensible login method IMO. Of course, it would depend on having some way to assign LDAP groups to external accounts (hence, wikitech SUL migration probably).

Could probably use mod_authnz_fcgi with something like mediawiki/oauthclient? Anyway this is blocked on having some connection between LDAP and SUL (so T148048: Store Wikimedia unified account name (SUL) in LDAP directory I guess?).

Would suck to have to install PHP just for that but I get your point: can do it indirectly via authnz_fcgi or similar.

I think authnz_fcgi allows the CGI script to be hosted remotely so it could be centralized (and then use something like mod_session to remember the user).

Also see T48146

Sorry for the off-topic. Maybe we should move towards using 2FA for gerrit instead, and require it for people with +2 access on mediawiki as well as those on ldap/{wmf,ops}, operations/puppet, Gerrit Administrators, Gerrit Managers, and other sensitive places/groups. @Paladox Does Gerrit support 2FA?

Gerrit dosent support 2fa as far as I know.

In T147864#4924028, @MarcoAurelio wrote:

Does Gerrit support 2FA?

Currently the two-factor protection for Wikimedia developer accounts must be handled by the Wikitech MediaWiki deployment. The Time-based One Time Password (TOTP) second factor we use must always be checked with access to state information about other attempts to use the token. This is a protection against replay attacks: Alice provides TOTP token to Service A, Mallory intercepts TOTP token in transit between Alice and Service A, Mallory provides TOTP token + credentials for Alice to Service B before the token expires. We protect against this by recording (user, TOTP token) pairs and checking to ensure that the same TOTP token has not been used previously. The best way to start enforcing 2FA protection across multiple applications using Wikimedia developer accounts (LDAP) would be to implement a true single sign-on (SSO) service like Kerberos or SAML. See also T179463: Create a single application to provision and manage developer (LDAP) accounts.

Just to clarify: Does gerrit.wikimedia.org currently use idp.wikimedia.org for login, or does it use LDAP authentication?

In T147864#10538325, @Arendpieter wrote:

Just to clarify: Does gerrit.wikimedia.org currently use idp.wikimedia.org for login, or does it use LDAP authentication?

Gerrit currently connects directly to the same LDAP directory that powers idp.wikimedia.org.

I understand that Gerrit uses LDAP, but that doesn’t provide true single sign-on since authentication still occurs locally. Should it instead use CAS-SSO for developer single sign-on, e.g., idp.wikimedia.org? Is this what the issue is about?

In T147864#10541714, @Arendpieter wrote:

I understand that Gerrit uses LDAP, but that doesn’t provide true single sign-on since authentication still occurs locally. Should it instead use CAS-SSO for developer single sign-on, e.g., idp.wikimedia.org? Is this what the issue is about?

I think the original ask here was for non-Developer account OAuth, but I would agree that CAS-SSO backed single sign-on is a more reasonable change to consider. The folks who are imagining that we can use something that piggybacks on SUL auth are being very hopeful about new solutions arising related to Developer accounts.

I would not be against work on changing the Gerrit authentication flow, but I have not seen any appetite for such changes from management circles so I would not expect any movement in the near term. This task was started by someone who felt that keeping track of separate accounts was cumbersome for them personally. It has not been driven by any user research, product planning, or informed discussion about the various restrictions and trade offs involved in changing Gerrit configuration.

There is Gerrit OAuth2 authentication provider: https://github.com/davido/gerrit-oauth-provider

@hashar What is this stalled on? (I understand T147864#10541736 that it’s not a priority right now, but “stalled” is stronger than “not a priority”. I’d also appreciate true SSO.)

In T147864#11313368, @Arendpieter wrote:

There is Gerrit OAuth2 authentication provider: https://github.com/davido/gerrit-oauth-provider

The documentation describes configuring OAuth2 without any plugins. Which is no surprise, as Google itself also uses SSO (I guess using OAuth2).

It is stalled because that is merely a which list and it is definitely not a priority.

Before that can be acted on there is a thorough analysis of what needs to be done. Notably:

• the OAuth2 Gerrit plugin has to be tested with our Apero CAS
• the Gerrit users (username scheme) are mapped to LDAP accounts (gerrit scheme`) using cn and we'd like to remap using uid
• manual changes will be required to refs/meta/external-ids (see https://gerrit.wikimedia.org/r/Documentation/config-accounts.html#_transition_from_ldap_to_google_oauth )
• we have ten of thousands of accounts in Gerrit, most of them have long been inactive

All of that to say it is a sizeable set of work that we would need to resource it (possibly as part of the annual planning) and there is little incentive to achieve it for now. So it is stalled in the sense it is neither Declined nor Resolved ;)