qgil wrote on 2014-04-04 06:41:06 (UTC)

https://secure.phabricator.com/book/phabricator/article/configuring_accounts_and_registration/

Alright, so many identificator providers may coexist. We could create one for Wikimedia (could we or would it make sense to add another one for Wikitech?), and then it is really up to us to add GitHub, Google, Facebook, Amazon, Persona... Once you have created your account, you can add more identifiers.

It is still unclear to me how can you "claim" the email addresses used in your patches and bug reports, in order to get those patches and tasks related to your username, but maybe this is a separate task?

Krenair wrote on 2014-04-20 16:29:21 (UTC)

Why don't we have both LDAP and Wikimedia CentralAuth (via OAuth2) as possible auth providers?

qgil wrote on 2014-04-21 02:22:07 (UTC)

Demonstrating Wikimedia SSO would be useful already in this instance, as part of the Phabricator RfC. Is it difficult to set up?

qgil wrote on 2014-04-21 17:04:58 (UTC)

Wikimedia Unified Login should be certainly part of the mix. Do we want to add compatibility with LDAP Wikitech accounts?

If I read the documentation correctly, user can merge these different identities under their Phabricator username. This would support these likely cases:

• Wikimedia user @WikiEnthusiastic creates an account in Phabricator, and then discovers that their Wikimedia credentials would have been enough. After logging again through Wikimedia SUL, he is able to merge both under the same identity.
• Wikimedia developer is known as HelpfulMary in Wikimedia projects, as HelpfulMaryDev in Wikitech-Gerrit-Labs, and a helpful@mary.org in Bugzilla. She can claim her previous work under a single Phabricator ID.

robla wrote on 2014-04-21 17:20:36 (UTC)

The fact that Phabricator lets you bind to multiple authentication providers is kinda awesome, and is going to simplify many things. However, we still have one complicating factor here, which is that the actual user identifiers are first come, first serve. So, if I happen to be first, I could register "qgil" as my username, then associate that account with "User:RobLa" on Wikipedia. The system is really none-the-wiser; it would happily give me "qgil" or "jimbo" or whatever I want.

Some things can be fixed after the fact by renaming users (Phabricator supports this), but there are ample disclaimers in the "Change Username" interface such that it's pretty clear leaning on it too heavily is fraught with danger. We may need to force authentication through SUL in order to claim a username in use on the projects, which may require some Phabricator customization to pull off well.

Krenair wrote on 2014-04-21 17:38:17 (UTC)

@Qgil: As we can have multiple different identity sources, I think it would make sense to support most of the major ones Wikimedia uses, so:

• CA/SUL (most public wikis)
• LDAP used for Wikitech/Labs/Gerrit
• Wikimedia Google accounts (mostly for staff)

@RobLa: Hmm... Maybe it should require the SUL name, but why not another system instead?

qgil wrote on 2014-04-21 19:06:20 (UTC)

Finding out that someone else got Qgil (SUL) / QuimGil (LDAP) with obscure intentions would be kind of awkward, but how big of a problem would this be? I would still be the only one able to connect with my account the email addresses that describe my activity in Bugzilla and Git/Gerrit.

Maybe we can populate the table of usernames with SUL / LDAP in order to minimize this problem?

It looks like we could just disable the "Username/Password" provider in the Wikimedia Phabricator instance, forcing users to create accounts through their Wikimedia LDAP or SUL accounts.

LDAP accounts have username and email address, both required in Phabricator. If we could pre-fill our Ph table of users with the LDAP data, that would bring us a long way. LDAP users would only need to reset their passwords and log in.

Is SUL also requiring email address? Email is still optional in Wikimedia sites. What would happen if a user without email defined in their SUL account wants to log in for the first time to Phabricator?

Phabricator users can add email addresses to their account. I wonder if this option could be used to associate your contributions to Bugzilla, Git, and Gerrit to your Ph account.

Wikimedia Google accounts... I don't see the benefit, This is in fact the service I used to register with my wikimedia.org account in http://secure.phabricator.com , but in our context here any WMF employee is expected to have a Wikimedia SUL account (and anybody in the Engineering department should have a LDAP account as well). Even if at the beginning I was quite enthusiastic about using many providers, maybe it makes sense to use only Wikimedia SUL / LDAP?

mattflaschen wrote on 2014-04-29 00:08:29 (UTC)

Even if at the beginning I was quite enthusiastic about using many providers, maybe it makes sense to use only Wikimedia SUL / LDAP?

I think Wikimedia SUL, plus local signup, may be enough going forward, especially if SUL finalization is done by then. I think most people with a Wikitech/LDAP login also have a login on the main projects (SUL), and if not, this is a good time to get one.

For people without a SUL account, we could even consider creating one when they create an account on Phabricator. I'm not sure how troublesome that would be on the CentralAuth side.

It would be good to also import the existing Bugzilla users, but I'm not sure how feasible that is.

qgil wrote on 2014-04-29 00:29:52 (UTC)

For people without a SUL account, we could even consider creating one when they create an account on Phabricator.

+1 because in practice this means that we support Wikimedia SUL only. Simple.

It would be good to also import the existing Bugzilla users, but I'm not sure how feasible that is.

It is probably better to let them register with SUL and then claim their email addresses via http://fab.wmflabs.org/settings/panel/email/

I'm not sure whether this would connect automatically their usernames with the bugs & comments imported and associated with their email addresses. It is something to consider when planning the migration. Related: T39#27.

csteipp wrote on 2014-04-29 15:57:38 (UTC)

Supporting "SUL" might be problematic, depending on the definition. If you're thinking sharing cookies with CentralAuth, I would generally discourage this. We currently can tolerate minor security issues (e.g., XSS that only affects older IE) on Bugzilla because we're not sharing authentication. If we do share authentication, then it becomes a liability for us.

The current OAuth extension doesn't support OAuth2 yet. I'll try and figure out what flows phabricator needs, and if that's one we're likely to support.

qgil wrote on 2014-04-30 17:23:18 (UTC)

Alright, this means that

• users logged in to e.g. mediawiki.org will not be automatically logged in to Wikimedia Phabricator
• but users with an account in e.g. mediawiki.org will be able to log in to Wikimedia Phabricator with the same credentials

This scenario requires that we support OAuth 2.0 in the Wikimedia cluster, which is not a trivial task.

What do you think about making this a blocker for the Wikimedia Phabricator deployment? The benefits would be huge, but the commitment to deliver this feature is expensive. It seems to be one of those features that would need to be enabled since day 1, although maybe there is another sensible, more flexible scenario. It would be also good to know if anybody else would benefit from having OAuth 2.0 implemented in Wikimedia servers.

In any case, I will link this task with the need for proper resourcing.

csteipp wrote on 2014-04-30 19:40:52 (UTC)

Just a minor update, it looks like Phabricator supports twitter and jira OAuth 1 providers. It looks like it would be fairly simple to integrate mediawiki's OAuth 1 provider as an auth plugin, if we don't want to wait on using OAuth2. (note to future self, it looks like we can call and verify mediawiki's /identify method in the getAccountID() call)

mattflaschen wrote on 2014-05-06 00:49:54 (UTC)

For people without a SUL account, we could even consider creating one when they create an account on Phabricator.

Before I was thinking that people could create a Phabricator account (using the normal Phabricator account creation flow), then we would create a CentralAuth account behind the scenes.

But if our OAuth flow allows creating accounts just prior to authorization (which it seems like it does, if you explicitly click Join MediaWiki), that's not necessary.

qgil wrote on 2014-05-10 08:45:01 (UTC)

https://www.mediawiki.org/wiki/Requests_for_comment/Phabricator/Plan#General says:

Users log in to Phabricator with their Wikimedia credentials.

Can we close this task agreeing that this is the provider selected? Wikimedia credentials, no less, no more.

gpaumier wrote on 2014-05-10 08:56:08 (UTC)

I wouldn't close the door on other (external) identity providers. Wikimedia credentials make a lot of sense for most of our current audience (MediaWiki developers and Wikimedia editors); but since we're discussing increasing the number of partnerships with other organizations (upstream, downstream, software user groups, etc.), it would make sense to let them use existing credentials from another identity provider (the usual suspects being Google, Persona, GitHub, OpenID, etc.) instead of having them create an account on Wikimedia sites that they don't have any use for.

tl;dr: Using Wikimedia credentials as primary identity provider sounds good, but if it's possible to keep others without too much overhead, I think there would be value in leaving that door open.

scfc wrote on 2014-05-10 15:43:08 (UTC)

+1 to @gpaumier. If Wikimedia OAuth[12] is ready by Day 1, that would be awesome, but what's the harm in allowing for example Google accounts as well?

qgil wrote on 2014-05-10 21:08:17 (UTC)

We could also allow users to sign-in to Wikipedia with the thir Google, Facebook, Twitter accounts, but we are not doing it. Why not? And could be the same reasons applicable here?

scfc wrote on 2014-05-10 23:24:40 (UTC)

@Qgil:

We could also allow users to sign-in to Wikipedia with the thir Google, Facebook, Twitter accounts, but we are not doing it. Why not? And could be the same reasons applicable here?

If I remember last year's discussions on wikitech-l correctly, the main obstacle was that MediaWiki wasn't built with that in mind, Extension:OpenID hasn't been properly reviewed yet, etc. AFAIUY, Phabricator has tested and deployed support for acting as an OpenID consumer.

qgil wrote on 2014-05-13 18:58:39 (UTC)

Moving this task back to the discussion board. Reassigning it to... me? because this is ultimately a community decision.

There are two questions here:

1. Are we not allowing users to use Facebook/Twitter/Google login credentials in Wikimedia servers because MediaWiki cannot handle this feature or because we have another type of objection about it?
2. If the only problem for using 3rd party authentication providers is a MediaWiki limitation that we don't have in Phabricator, would it be ok to offer these alternative authentication providers in our Wikimedia Phabricator instance in production?

If offering 3rd party providers is fine, then we can discuss which ones.

jdforrester wrote on 2014-05-13 19:51:22 (UTC)

Are we not allowing users to use [third party logins] because we have another type of objection about it?

Yes. Endless arguments about this, but ultimately it comes down to privacy/pseudo-anonymity and approving by selection of some services over others.

swalling wrote on 2014-05-13 20:18:14 (UTC)

There are two questions here:

1. Are we not allowing users to use Facebook/Twitter/Google login credentials in Wikimedia servers because MediaWiki cannot handle this feature or because we have another type of objection about it?
2. If the only problem for using 3rd party authentication providers is a MediaWiki limitation that we don't have in Phabricator, would it be ok to offer these alternative authentication providers in our Wikimedia Phabricator instance in production?

The answer to #1 is "it's complicated". The answer for #2 is IMO, yes. The support for this already exists in Phabricator, and offering multiple providers is a great way to reduce the potential barrier to entry. As long as we keep the number of additional providers to a minimum (i.e. not the eight different ones secure.phabricator.org provides) and choose some sensible ones (Google, GitHub, Persona, for examples) then I think it's a great idea.

csteipp wrote on 2014-05-13 21:12:51 (UTC)

If I understand the concerns right, most of them are about privacy, and how letting users login with google/etc makes it easy for our users to tell the auth provider the correlation between their IP and username. Some people argue that we have a duty to not let users shoot themselves in their privacy foot, or that by having the login there, we're somehow implying that these organizations have a compatible privacy policy with our own. I don't think either are necessarily true, and we could make the relationship explicit if we wanted to.

We will want to audit the modules for security, and possibly hack in some sort of messaging that says it's up to the user to protect their own privacy. But otherwise I don't see any issues with turning on other providers.

avive wrote on 2014-05-14 00:44:05 (UTC)

As an outside user, I think it would be odd to allow other providers in wmf:phab, and not in wm.

Since wmf:phab is part of the wmf "system", I'd expect it to ideally only support wm logins: one, it's obviously connected, and two, sso rocks. I think it's reasonable from privacy POV that they share logins, but I might be wrong here.

Allowing (say) google auth for phab but not for wm is nicer than not allowing it at all, but also a bit confusing. Don't I need a WM account to effectively use phab?

Also consider the future were WM does allow google auth: Will loging in with google to phab automatically link my wm-account, because it's already linked to my google account? This is somewhat confusing.

Of course, offering many auth forms for wm itself is something I'd be happy to see.

(tl;dr: I'd vote to allow only wm oauth for wmf:phab - assuming that's technically possible)

qgil wrote on 2014-05-14 17:09:30 (UTC)

We are a small sample of the community and we are seeing very different opinions here. Being Phabricator still so abstract for most of our community members, I don't see the usefulness to start a wider community discussion now.

What if we focus on a plan for a Wikimedia-specific login for Day 1, leaving the third parties for later? It is easier to add options as they are being agreed than to remove them if they cause too much trouble.

mattflaschen wrote on 2014-05-15 05:52:31 (UTC)

scfc:

Extension:OpenID hasn't been properly reviewed yet, etc. AFAIUY, Phabricator has tested and deployed support for acting as an OpenID consumer.

Connect with Google/Facebook/etc. use OAuth. They do not require OpenID.

jdforester:

Yes. Endless arguments about this, but ultimately it comes down to privacy/pseudo-anonymity and approving by selection of some services over others.

Additionally, I am skeptical about adding a dependency on a proprietary third-party service. Done wrong, the dependency becomes permanent (i.e. it is coded in such a way that the user can not disconnect their account). Otherwise, we still have the significant privacy and open source software issues to consider.

I would prefer to keep it "Login with your Wikipedia/Wikimedia account" for day 1.

qgil wrote on 2014-05-15 17:56:41 (UTC)

About local user creation, what about removing it? If you have to create an account, you might as well create it for the whole Wikimedia, not only the Phabricator instance.

Therefore, the proposal for Day 1 is simple: Wikimedia SUL.

jdforrester wrote on 2014-05-15 18:37:59 (UTC)

Therefore, the proposal for Day 1 is simple: Wikimedia SUL.

Agreed; task description/detail changed accordingly.

swalling wrote on 2014-05-15 20:35:27 (UTC)

Therefore, the proposal for Day 1 is simple: Wikimedia SUL.

I really don't think this is a good idea.

Turning off local creation and deferring third party providers will create inertia against adding additional authentication tools. We should pick the set we want from day one.

It particularly makes no sense to not consider third party tools when we would not have to do technical work to support them. All we have to do is pick a list.

qgil wrote on 2014-05-15 20:59:04 (UTC)

I might be wrong, but I believe this could be a contentious topic. We don't need more contentious topics for Day 1.

In any case, we cannot decide here to add 3rd party providers and to choose which ones. We can safely default to Wikimedia SUL for Day 1 and leave the door open to 3rd party providers agreed by the community. This discussion needs to go through wikitech-l. I'm happy to send a first email there and see how it goes.

swalling wrote on 2014-05-15 22:02:04 (UTC)

In any case, we cannot decide here to add 3rd party providers and to choose which ones. We can safely default to Wikimedia SUL for Day 1 and leave the door open to 3rd party providers agreed by the community. This discussion needs to go through wikitech-l. I'm happy to send a first email there and see how it goes.

Quim and I talked in person and I'm okay with this plan.

scfc wrote on 2014-05-15 22:21:30 (UTC)

@ mattflaschen:

Extension:OpenID hasn't been properly reviewed yet, etc. AFAIUY, Phabricator has tested and deployed support for acting as an OpenID consumer.

Connect with Google/Facebook/etc. use OAuth. They do not require OpenID.

The question was about authenticating MediaWiki against Google accounts, and currently Extension:OpenID appears to be the (only?) way to do that, and that uses OpenID which Google still supports and will do so until April 20th, 2015. Is there an extension that turns MediaWiki into an OAuth consumer?

Krinkle wrote on 2014-05-15 23:48:09 (UTC)

I'd recommend using our LDAP/Labs/Wikitech as the primary method of authorisation and identification.

Adding multiple backends could be neat, but I'm not sure it's worth the hassle and burden it might add to the system, it's usability etc.

Claiming an e-mail address for imported content from Bugzilla seems useful though, but if possible, I think it'd be ideal if we can configure it such that e-mail addresses can only be connected/claimed to an account (e.g. one logged-in with LDAP), but not allow users to create new accounts with only an e-mail address (so that we only have 1 "user name", the one in LDAP, and no potential for conflicts or confusion.

I think LDAP makes more sense as primary over Wiki CentralAuth / OAuth due to the context of this service. Our primary audience and use case is developers and designers. They are more likely to have or need an LDAP account than a wiki account. And if they're new to all this and are coming from the community with just a wiki account, they're going to need an LDAP account sooner or later anyway. So maybe (if not already) we can have a "Sign up" link in Phabricator, sure, but have it point to account creation of LDAP/Labs/Wikitech instead. If that sign up form is so bad, we ought to improve it.

Also remember they'll need one or more ssh keys, a user name, possibly a shelel name (depending on how git/ssh works in Phabricator), two-step auth maybe, all of which we have on Wikitech in LDAP.

swalling wrote on 2014-05-15 23:49:54 (UTC)

I'd recommend using our LDAP/Labs/Wikitech as the primary method of authorisation and identification.

This doesn't work for non-technical users reporting bugs etc. That includes most WMF staff in Product/Design, who don't all have Labs accounts

swalling wrote on 2014-05-15 23:50:33 (UTC)

Sorry, didn't mean to close this. The "close task" button is where Cancel usually is LOL.

robla wrote on 2014-05-15 23:58:46 (UTC)

The discussion in bug 14487 is relevant to this conversation.

qgil wrote on 2014-05-16 16:10:34 (UTC)

A question while we decide on LDAP and GitHub: do all these authentication methods provide only different accounts belonging to a same person, or will Phabricator allow to manage these different identities under one username?

At least from the user point of view, the ideal situation would be:

• I can get a MyUsername after logging in with my Wikimedia SUL (or LDAP or GitHub...) credentials.
• Once I have a user profile, I can link to my profile my other identities with other providers.
• I can also claim email addresses, which will help linking migrated Bugzilla data with my account as well.
• No matter how do I log in, my actions in Phabricator will always refer to one single username.

Users will always have the choice of keeping their different identities separate by not linking them to a single profile.

Is this feasible? Desired?

avive wrote on 2014-05-16 16:52:22 (UTC)

Phab lets you have 1 account, that is linked to as many auth methods as you'd like - they are all connected to the same Phabricator user. You can play with this on https://secure.phabricator.com/settings/panel/external/ (which have lots of auth methods enabled).

That being said, its also easy to accidentally create duplicate accounts by:

1. "Register with Facebook"
2. Log out, forget you've used Facebook for this.
3. "Register with Google"

which, since it can't guess this is the same person, may create a new account.
To reduce this, it's possible to only allow one/some providers to register, and others only for login.

mattflaschen wrote on 2014-05-17 00:03:17 (UTC)

scfc:

The question was about authenticating MediaWiki against Google accounts, and currently Extension:OpenID appears to be the (only?) way to do that, and that uses OpenID which Google still supports and will do so until April 20th, 2015.

You're right, I forgot Google supports OpenID.

Krinkle:

Claiming an e-mail address for imported content from Bugzilla seems useful though, but if possible, I think it'd be ideal if we can configure it such that e-mail addresses can only be connected/claimed to an account (e.g. one logged-in with LDAP), but not allow users to create new accounts with only an e-mail address (so that we only have 1 "user name", the one in LDAP, and no potential for conflicts or confusion.

It's not clear if Phabricator can actually use LDAP as its username database, or just let you create an account based on LDAP (the same way you can log in to a site via OAuth, but that consuming site has their own user table).

I think LDAP makes more sense as primary over Wiki CentralAuth / OAuth due to the context of this service. Our primary audience and use case is developers and designers.

I don't completely agree with this perspective. Getting staff members set up is not going to be an issue (even if a staff member doesn't yet have a Wikipedia or MediaWiki.org account, we have onboarding for that). So I would say, we are most concerned about reducing friction for volunteers.

This includes both content volunteers (not familiar with code, but see bugs on the wiki occasionally) and software volunteers. Content volunteers will often have an SUL account (they definitely will once SUL finalization is done), since they use Wikipedia/Wiktionary/etc. Software volunteers either already have a MediaWiki.org account or can get one easily.

And if they're new to all this and are coming from the community with just a wiki account, they're going to need an LDAP account sooner or later anyway.

I disagree with this. If they just report bugs, discuss features, they will never need an LDAP account. Our Phabricator should be open to constructive feedback from non-technical people.

Also remember they'll need one or more ssh keys, a user name, possibly a shelel name (depending on how git/ssh works in Phabricator), two-step auth maybe, all of which we have on Wikitech in LDAP.

(None of this is part of day 1, but it is relevant). You're right, it would be somewhat annoying to import the SSH keys again; maybe we can make some kind of one-time import bridge using OAuth against Wikitech and also authenticating against Phabricator's API. Shell names are not an issue, since it uses the same one for everyone, like GitHub.

Krinkle wrote on 2014-05-21 02:23:37 (UTC)

mattflaschen:

maybe we can make some kind of one-time import bridge using OAuth against Wikitech and also authenticating against Phabricator's API

That would be undesirable. This is not about migrating from Gerrit, but about splitting ssh keys into separate buckets. People with developer accounts (despite the appreciated effort to make it easier for volunteers) will remain the majority user of this software. And in my opinion (for time and money reasons) must also be optimised for highly (both for continued productivity by our core contributors as well as to make it easier for developers volunteers to contribute and get started).

Having two separate SSH key registries (one in LDAP for Labs/Wikitech etc, and one in Phab) should be avoided.

mmodell wrote on 2014-06-02 16:07:49 (UTC)

From a technical perspective, I think phabricator always has "local" accounts. It's just that it is flexible in allowing you to link your phabricator account to one or more external authentication providers. You can easily link and unlink any of the available providers at any time using familiar oauth flow.

mmodell wrote on 2014-06-02 16:11:24 (UTC)

@mattflaschen wrote:

It's not clear if Phabricator can actually use LDAP as its username database, or just let you create an account based on LDAP (the same way you >can log in to a site via OAuth, but that consuming site has their own user table).

No, phabricator does not "actually use LDAP as it's username database" .... it uses ldap like another oauth provider.

In T40#90, @Krinkle wrote:

Having two separate SSH key registries (one in LDAP for Labs/Wikitech etc, and one in Phab) should be avoided.

The ssh key registry in phabricator is specifically designed for accessing repositories hosted by phab. Compare with garrit's ssh key registry.

qgil wrote on 2014-06-02 22:12:17 (UTC)

Just fyi, the Trusted User Tool will be deployed before Day 1. It only requires Wikimedia SUL. This will give us a chance to understand better and test the connection between accounts and providers.

mmodell wrote on 2014-06-02 23:09:12 (UTC)

I already ran into an issue with reliability of the phabricator oauth plugin. I need to test further and get this rock solid reliable.

mattflaschen wrote on 2014-06-12 03:54:32 (UTC)

It looks like the initial version of this is implemented (cool!) at http://fab.wmflabs.org/settings/panel/external/, but it's showing the Amazon.com logo. We should just hide the Amazon.com logo (CSS .login-MediaWiki {display: none} ) until the logo can be done properly.

qgil wrote on 2014-06-12 04:57:18 (UTC)

Damn, our s3kr37 plan to move the hosting of all Wikimedia projects to AWS has been leaked!!!

csteipp wrote on 2014-06-12 16:23:57 (UTC)

In T40#97, @mattflaschen wrote:

It looks like the initial version of this is implemented (cool!) at http://fab.wmflabs.org/settings/panel/external/, but it's showing the Amazon.com logo. We should just hide the Amazon.com logo (CSS .login-MediaWiki {display: none} ) until the logo can be done properly.

I gave Chad my ugly version of our logo (anyone else is welcome to cleanup my sprite). I'm happy to send the patch to anyone else with shell on that box.

qgil wrote on 2014-06-12 16:45:17 (UTC)

fwiw we should use this logo: https://commons.wikimedia.org/wiki/File:Wikimedia-logo.svg

csteipp wrote on 2014-06-12 21:01:55 (UTC)

Wrench in plans. Phabricator only supports very limited usernames: "Usernames must contain only numbers, letters, period, underscore and hyphen, and can not end with a period. They must have no more than 64 characters." Which means a ton of MediaWiki usernames can't be used as the Phabricator username.

Do we,
a) Try to fix Phabricator, and continue with the current plan
b) Come up with a new plan

mattflaschen wrote on 2014-06-13 03:54:56 (UTC)

In T40#101, @csteipp wrote:

Wrench in plans. Phabricator only supports very limited usernames: "Usernames must contain only numbers, letters, period, underscore and hyphen, and can not end with a period. They must have no more than 64 characters." Which means a ton of MediaWiki usernames can't be used as the Phabricator username.

This comes back to the important fact that (as currently configured at least) Phabricator has its own set of usernames, independent of MediaWiki's, even though they can be linked with OAuth. mmodell said above even the LDAP integration works like this ("No, phabricator does not "actually use LDAP as it's username database" .... it uses ldap like another oauth provider.")

I created the MediaWiki.org user PhabricatorTest&*^%. (yes, the period is part of the username). When I signed up using the OAuth flow, Phabricator prompted me (via a pre-fill) to use that username at first, but then said it was not valid for Phabricator (I forget if it was immediate, or required a submit).

I had the complete choice of which Phabricator username to use. I went with PhabricatorTest_____; however, it's still fully linked to the MediaWiki.org account with a different name (the screenshot below shows the linkage, but unfortunately not the Phabricator username).

csteipp wrote on 2014-06-13 21:02:00 (UTC)

In T40#103, @mattflaschen wrote:

In T40#101, @csteipp wrote:

Wrench in plans. Phabricator only supports very limited usernames: "Usernames must contain only numbers, letters, period, underscore and hyphen, and can not end with a period. They must have no more than 64 characters." Which means a ton of MediaWiki usernames can't be used as the Phabricator username.

This comes back to the important fact that (as currently configured at least) Phabricator has its own set of usernames, independent of MediaWiki's, even though they can be linked with OAuth. mmodell said above even the LDAP integration works like this ("No, phabricator does not "actually use LDAP as it's username database" .... it uses ldap like another oauth provider.")

Correct. As I put on the LDAP discussion (dear phabricator, why is it so hard to find the permalink to a comment I made?), "As for the conflict, and what takes precedent-- The unique identity in Phabricator is the Phabricator username. Those identities can use other authentication mechanisms (LDAP, OAuth) to sign into those accounts. But that's the username that shows up in comments, commits, etc."

So yes, the reality we have to deal with is Phabricator will introduce another identity (i.e., username) into our developer eco system. So the discussion is how do we make that as seamless / transparent as possible.

1. We allow any Phabricator username. That means if you're used to seeing "CSteipp" comment about stuff gerrit (or csteipp@wikimedia.org in bugzilla), I may chose "OMGKitties" for my phabricator name, and everyone has to get used to that. Any sane linking of gerrit / bugzilla comments to my new identity can't happen automatically.

2. (failed) We were going to force you use your WMF/SUL username, but phabricator's rules don't allow us to do that without a major change to Phabricator.

So we kinda back to brainstorming about the best road forward. Let me propose:

3. We pre-import and pre-link LDAP accounts for day 1. We (during import) control the username, and developers "claim" their account by logging in with LDAP. Only issue would be if LDAP usernames don't comply with Phabricator's rules. Does anyone know? (maybe @Rush or @laner knows?)

4. We ask really nice that developer use their gerrit, bugzilla, or SUL account name, and rely on policy to enforce naming convention.

5. ???

laner wrote on 2014-06-13 21:05:00 (UTC)

LDAP names are restricted to anything MediaWiki allows, unless you're considering the shell account name, which is much more greatly restricted (alpha-numeric, underscore, and dashes, I think).

qgil wrote on 2014-06-13 21:18:52 (UTC)

Well, it's not that there are no users of xx.wiki trying to "get their username" in yy.wiki because someone else was using the exact username before the SUL merge. I mean, we are not going to get a perfect solution ever. Pre-populating wiith LDAP data + let it flow + assume good faith might be just enough.

If there is an evident case of abuse (my real name is OMGKitties and csteipp is impersonating me to confuse everybody) then we can always act upon it.

Rush wrote on 2014-06-13 21:37:53 (UTC)

Hopefully I can provide something useful here. I have come up against a bit of a issue that will somewhat dictate this. It goes like this: we want to import an rt ticket, it's assigned to a username, and created by a username, and more usernames have commented. So in order to meaningfully import ticket history (linked to users in the usual phabricator ways) we would have to import entire blocks of users from the ticketing system of origin. I haven't worked out exactly if / how that's possible. It may be sanest to do generic metadata for imported tickets, but I think no one will love that, including me. So once I get time I will explore the possibilities of user mass-import. This also means we need to consider identities outside of SUL since that is where the tickets are being imported from, and that is the context under which the associations will be meaningful.

Some people may have different usernames _currently_ in our systems. I know it is my folly that I am cpettet in rt and rush elsewhere, and then chasemp in chat. Why I ever considered this I don't know. But it means that the above importing gets weird. Hopefully these instances are small and people are smarter than I. It is my hope that truly abhorrent instances of this kind of thing are few.

I think having consumed this thread now that there is a lot of good, if not overwhelming, ideas here. My suggestion is that we have reached the point of rubber-and-road where we need to see what works with phabricator and SUL enabled. The SUL stuff currently being under review (or at least a stripped down version of it) this seems like we can do some real figuring soon.

An outline I am intending to test once we get there:

1. People will have a Phabricator account. This account name you can choose at the time of account association with an existing entity. There is no way around this. yes, someone could choose to be known as ActuallyPolPot. That isn't a bug but a feature :) I think :)

2. Existing authentication providers from the beginning: Wikitech/labs/gerrit LDAP & SUL. I have confirmed I can hook Phabricator up to the LDAP infrastructure that exists now. That means your SN registered through wikitech would be an account you can link through LDAP to a Phabricator account.

I am rush in wikitech ldap. I create a Rush account in Phabricator, this is done by logging into the ldap auth provider with my existing wikitech credentials. I can then associate my SUL account in the same way and both are now linked to one username in Phabricator. At least that is my hope.

3. Since we are allowing two authentication providers (LDAP and SUL) in the case of one being down the other is available, have to test the extent of this. My theory is anyone of technical acumen who will be responding to a SUL outage will have an account through wikitech. If they don't, they should :)

4. I do not intend to allow account registration with the local Phabricator, in that accounts cannot be created from nothing. They must exist in either LDAP or SUL in order to be associated with a Phabricator username.

The things I do not know are plenty:

• can we associate privs in phabricator to ldap groupings?
• how does the auth provider failover work for an account associated to both when one (SUL or LDAP) is down?

There is a great deal of consolidation that needs to happen. RT has standalone accounts -- these will no longer be relevant in themselves. Bugzilla has standalone accounts -- these will no longer be relevant in themselves. Wikitech/LDAP has accounts -- I do not intend to replace or augment this -- only hook into it. SUL has accounts -- I do not intend to replace or augment this only hook into it.

The further consolidation of wikitech / SUL / anything else is a big, big discussion. I think this approach keeps our existing secure registration processes (you have to use two-factor for example to change my LDAP password). We understand how to add users to wikitech. We understand how to add users to SUL. Let's preserve those mechanisms as authoritative for the time being.

I'm not sure yet how that plays out -- I think some version of csteipp's #3 suggestion is probably necessary.

Above all, let's get SUL in prod and test out what's actually possible.

csteipp wrote on 2014-06-13 23:10:55 (UTC)

In T40#108, @Rush wrote:

• how does the auth provider failover work for an account associated to both when one (SUL or LDAP) is down?

Since you click on the authentication mechanism when you get to the login page, if one is down the login flow just wont work.

As far as I can tell, the external logins are for login only, not authorization. So groups or ideas about rights in other systems aren't exposed to phabricator. So if LDAP is down, all my Phabricator rights still work.

Above all, let's get SUL in prod and test out what's actually possible.

Just let me know what you need! I have it setup locally, and helped chad setup the labs instance. Ping me on irc if you need help getting it up.

mattflaschen wrote on 2014-06-13 23:47:36 (UTC)

For context in the below, there are basically two ways existing systems can be imported:

• Just as text. Users A, B, and C commented on an RT or Bugzilla thread. The import includes their comments (either in comment 0, or as separate comments written by "Import script") and there is plain text that says "By Bugzilla user C", but they are not truly attributed in that the C Phabricator account owns the comments
• True user import with proper association (A, B, and C become Phabricator users, the comments are attributed to them in the normal Phabricator way, and they own them).

In T40#104, @csteipp wrote:

1. We allow any Phabricator username. That means if you're used to seeing "CSteipp" comment about stuff gerrit (or csteipp@wikimedia.org in bugzilla), I may chose "OMGKitties" for my phabricator name, and everyone has to get used to that. Any sane linking of gerrit / bugzilla comments to my new identity can't happen automatically.

I don't know that much about LDAP. But there has to be some kind of link table (mapping LDAP username => Phabricator username) on the Phabricator side. So, assume we pre-import LDAP accounts as suggested by @csteipp. That link table will then be fully populated.

Later (this is only relevant to phase 2), if we import existing Gerrit changesets into Phabricator's code review tool (Differential), the import script can consult that link table to map the usernames. This part is relatively straightforward (other aspects of a Gerrit ->Differential migration, if we did it, would be harder).

Bugzilla is a harder problem. Bugzilla already has its own identity (email), which is neither Wikitech/Gerrit/LDAP nor SUL. If we wanted to do a Bugzilla import with proper user association, one way is to create a temporary Bugzilla auth backend. We could then pre-populate users in the same way as LDAP (something would need to be done about merging accounts, though, due to many people having LDAP and Bugzilla), then maybe drop the Bugzilla auth backend afterwards (people could somehow regain access via their email, which would be stored on the Phabricator side).

SUL isn't currently used for anything we're importing from, so it's not an issue there.

3. We pre-import and pre-link LDAP accounts for day 1. We (during import) control the username, and developers "claim" their account by logging in with LDAP. Only issue would be if LDAP usernames don't comply with Phabricator's rules. Does anyone know? (maybe @Rush or @laner knows?)

That seems reasonable, but not essential. Bear in mind that people don't necessarily use a similar name/email for Bugzilla (and we're actually importing/replacing Bugzilla first), let alone SUL. And even if we solved all that, it still wouldn't do anything for IRC.

It will all end up being a net win long-term if we can actually import both Bugzilla and Gerrit, since then it's one username for bug tracking and code review by definition, since it's one system.

In T40#108, @Rush wrote:

Your action plan/questions all seem good.

Hopefully these instances are small and people are smarter than I. It is my hope that truly abhorrent instances of this kind of thing are few.

I used to be superm401 (SUL and IRC), mflaschen@wikimedia.org (Bugzilla), mflaschen (production), and mattflaschen (Labs/Gerrit). Now I'm down to three thanks to the Labs/production username consolidation.

So it's not that unusual.

We could consider exposing the SUL and/or LDAP usernames on the Phabricator user page. That would make things a little easier.

mattflaschen wrote on 2014-06-13 23:53:21 (UTC)

In T40#109, @csteipp wrote:

In T40#108, @Rush wrote:

• how does the auth provider failover work for an account associated to both when one (SUL or LDAP) is down?

Since you click on the authentication mechanism when you get to the login page, if one is down the login flow just wont work.

I think @Rush was asking about an account with both SUL and LDAP associated with a single Phabricator account. Could it then log in via LDAP when SUL is entirely down? My guess is yes (and vice versa if only LDAP is down), but it's an important question, and I have no direct evidence (it would be nice to hook LDAP up to Labs to test this, if possible).

csteipp wrote on 2014-06-16 17:43:42 (UTC)

In T40#111, @mattflaschen wrote:

In T40#109, @csteipp wrote:

In T40#108, @Rush wrote:

• how does the auth provider failover work for an account associated to both when one (SUL or LDAP) is down?

Since you click on the authentication mechanism when you get to the login page, if one is down the login flow just wont work.

I think @Rush was asking about an account with both SUL and LDAP associated with a single Phabricator account. Could it then log in via LDAP when SUL is entirely down? My guess is yes (and vice versa if only LDAP is down), but it's an important question, and I have no direct evidence (it would be nice to hook LDAP up to Labs to test this, if possible).

I haven't fully tested the exact scenario, but I'm 99% sure the answer is yes. Just based off the way the OAuth auth works.

mmodell wrote on 2014-07-29 16:35:36 (UTC)

Can't we mark this as done?

mattflaschen wrote on 2014-07-31 04:24:29 (UTC)

In T40#114, @mmodell wrote:

Can't we mark this as done?

Yeah. That implies marking the GitHub as WONTFIX (since it says "Support only WMF SUL"). Going ahead and doing so, since no one at T337: Set up weekly RfC Wednesday meetings has come out strongly in favor of it, and there are various issues (not necessary, depending on a proprietary third party site to login, privacy, etc.)

mattflaschen wrote on 2014-07-31 04:26:44 (UTC)

And LDAP, since that also seems to be decided per T338: Regular checkin with Engineering managers in Friday meeting.

importing issue status

In T657, the description asks:

Do you, the guys at the Wikimedia Foundation, plan on allowing users to link their Phabricator accounts to external accounts originating from sites other than those of the WMF, like Google, Twitter, etc., …?

In T657#11122, @chasemp wrote:

this question is probably a good candidate to have in a faq type document as I'm sure it will come up again

…but where to put something like that, exactly?

In T16#11741, @RandomDSdevel wrote:

…but where to put something like that, exactly?

Now it's here: https://www.mediawiki.org/wiki/Phabricator/FAQ#Why_can.27t_I_login_using_my_GitHub_or_Google_account.3F, visibly linked in the description of this task.

In T16#12027, @Qgil wrote:

In T16#11741, @RandomDSdevel wrote:

…but where to put something like that, exactly?

Now it's here: https://www.mediawiki.org/wiki/Phabricator/FAQ#Why_can.27t_I_login_using_my_GitHub_or_Google_account.3F, visibly linked in the description of this task.

OK, thanks!