Krenair wrote on 2014-05-16 16:12:39 (UTC)

I don't think OAuth was implemented at the time, Quim.

mattflaschen wrote on 2014-05-16 23:34:13 (UTC)

@Qgil:

Is there a problem of conflicting usernames? What if I'm JustADev in Wikimedia, but then JustADev in Wikitech is someone else?

My guess is it uses the source username (e.g. your username on SUL/MediaWiki.org) as a suggestion, but if there's a conflict it makes you pick a new one. So when the first JustADev registers, they just get it, but the second's account is linked, but with a different Phabricator username.

I assume there can not be duplicate Phabricator usernames (that would clearly cause issues).

The main advantage to this proposal is that people can just use their existing Gerrit username (I would guess more people think of these as their Gerrit credentials than their Wikitech credentials, even though they're actually the same).

But most of these people also have MediaWiki.org credentials, so I don't see this as necessary.

qgil wrote on 2014-05-30 01:02:20 (UTC)

In T338#9, @mattflaschen wrote:

The main advantage to this proposal is that people can just use their existing Gerrit username (I would guess more people think of these as their Gerrit credentials than their Wikitech credentials, even though they're actually the same).

But most of these people also have MediaWiki.org credentials, so I don't see this as necessary.

I agree. When most if not all LDAP users can login with their mediawiki.org aka Wikimedia SUL credentials, what is the point of maintaining an additional LDAP plugin?

robla wrote on 2014-05-30 17:17:49 (UTC)

If Phabricator is to fully replace Gerrit, it needs LDAP. I'm pretty sure Ops considers this non-negotiable. It needs to be a database distinct from our production site, subject to separate policies (i.e. the policies currently maintained by Ops for our LDAP instance, which are very different than the policies of the production cluster). A big reason for keeping the distinction is that we want to avoid making our sole mechanism for modifying production wholly dependent on production.

qgil wrote on 2014-05-30 17:43:01 (UTC)

Feedback from Ops is welcome.

jkrauska wrote on 2014-06-09 14:41:13 (UTC)

From an IT perspective -- if we wanted to expand some of Phab* to 'corporate' needs (eg. IT helpdesk tickets and/or general project planning tool), the preference would be to use our 'corp' LDAP servers.

I would wager to say that maybe 30% of the WMF organization does not have Wikitech or MediaWiki.org creds.

There's also a fairly strong layer of controls on the IT LDAP accounts.

Perhaps a system that allows for multiple concurrent auth systems could serve the most users without being too difficult to obtain an account...

It does outline the parallel that just as we have 'too many' planning and tracking tools, we have 'too many' auth systems. :)

Since I don't have much of the backstory here: Who are the primary 'users' of our proposed Phab system?

aklapper wrote on 2014-06-09 16:21:54 (UTC)

To summarize: We'd need LDAP auth for replacing Gerrit (and potentially for IT as a potential future Phab customer).
As we do not plan to replace Gerrit for Day 1 (T42, T277), is there any other usecase/requirement not brought up yet that would make providing LDAP auth block Day 1?

@Rush, @faidon, @andrewbogott, @Dzahn: Feedback welcome from ops.

Rush wrote on 2014-06-09 16:41:53 (UTC)

I don't have a perfect understanding of how all of the various authentication systems interact now, otherwise I would try to provide some clarity here. But having this solely be hinged for access on the SUL mechanism does seem problematic if we widely publish this as the 'tool of tools' and then it's not up for people to check the status of ongoing outages or other issues that affect SUL itself. I also don't know yet about conflicting usernames, it seems SUL usernames when there is a conflict will take precedence? I think some investigation is in order for handling multiple mechanisms upfront even if they are not blockers just to prevent a truly serious problem after this first hurdle. I will try to get some more technical details on this from an ops perspective in the next week or so.

csteipp wrote on 2014-06-09 17:07:51 (UTC)

In T338#17, @Aklapper wrote:

To summarize: We'd need LDAP auth for replacing Gerrit (and potentially for IT as a potential future Phab customer).
As we do not plan to replace Gerrit for Day 1 (T42, T277), is there any other usecase/requirement not brought up yet that would make providing LDAP auth block Day 1?

This probably depends on if / how much of the history in gerrit we bring over, but if someone registers (using ldap or mediawiki) and sets their Phabricator Username to a name that was used by someone else in gerrit, that seems like it could cause confusion. I personally see gerrit as one of the most important identities that we're planning to integrate, since that's one of the few places you really want to know who did something years in the past.

We could attempt to prepopulate the Phabricator users with the gerrit users, or if we make sure we have a process to cleanly usurp accounts from someone who (maliciously) creates accounts with other people's gerrit username then we can just respond if it does happen.

Either way, I think we need LDAP (external, not OIT) integration as early in the process as possible.

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

In T338#19, @Rush wrote:

I don't have a perfect understanding of how all of the various authentication systems interact now, otherwise I would try to provide some clarity here. But having this solely be hinged for access on the SUL mechanism does seem problematic if we widely publish this as the 'tool of tools' and then it's not up for people to check the status of ongoing outages or other issues that affect SUL itself. I also don't know yet about conflicting usernames, it seems SUL usernames when there is a conflict will take precedence? I think some investigation is in order for handling multiple mechanisms upfront even if they are not blockers just to prevent a truly serious problem after this first hurdle. I will try to get some more technical details on this from an ops perspective in the next week or so.

Very much agree. A backup to mediawiki auth is mandatory, and our existing LDAP system seems like the best fallback (creating users with passwords in the phabricator db seems like one more identity silo, and unnecessary security exposure).

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.

As far as I can tell, there isn't a way in the interface to clearly see what external accounts are linked with a Phabricator username.

qgil wrote on 2014-06-11 22:34:23 (UTC)

In T338#15, @JKrauska wrote:

I would wager to say that maybe 30% of the WMF organization does not have Wikitech or MediaWiki.org creds.

No Wikimedia Foundation employee should have any objection to create their own Wikimedia account. Maybe they didn't have a reason to have it before, if they need to use Phabricator, then now they will have a reason to have one.

All things considered, I still believe that the most solid approach is to require Wikimedia SUL to register an account, and then user can add other approves providers via http://fab.wmflabs.org/settings/panel/external/

qgil wrote on 2014-06-12 16:42:10 (UTC)

I'd say let's focus on the plan for Day 1 in a way that doesn't block any of the problems to be solved after that. We need such plan for Day 1 soon, while we have many months to solve the +2 / code review implications.

According to the discussion, the main case for LDAP in Day 1 is to have a backup in case SUL is down. Would this plan for Day 1 satisfy the LDAP use case?

1. All users register their account with Wikimedia SUL. If you don't have one, get one.
2. Once users are registered, they can claim their Labs LDAP identity via Settings - External accounts. This is how we avoid any potential username conflicts created by Phabricator.
3. (To be discussed: maybe there is a way to import whatever is needed to "populate" the SUL and LDAP details of all Labs LDAP users?)

In this scenario, if SUL is down, can users still login with their LDAP credentials?

permission to the security bug queue

This is relevant to Day 1. Our goal is to replicate the setup we have in Bugzilla. Is there any connection between permissions for Bugzilla security bugs and LDAP?

Finally, I think we need our overall strategy on authentication methods should include UX properties: what's the path that we're offering to newcomers to become technical contributors? How do they upgrade from Wikimedia projects user to contributing?

This is a wider topic that we should discuss somewhere else. Still, I wouldn't change anything for Day 1. Logging to Phabricator will give you access to bug / task management, something that before would imply you to register to Bugzilla, RT, Mingle, and Trello. This is a big progress already. For code review etc you will still need to register at http://wikitech.wikimedia.org.

faidon wrote on 2014-06-12 17:26:02 (UTC)

(ignorig the OIT aspect of this for now -- it's complicated enough as it is :))

Besides the security perspective that Rob/Chris already talked about, there's an important distinction to be made here: identity is much more than authentication; LDAP currently provides much more than SUL.

Right now, in the Labs LDAP we have information that cannot be represented or exchanged with SUL (afaik): we have a posix UID, a shellname (username for shell login, without spaces and funky characters), an SSH key to be used for authenticating to machines, settings such as home directories, preferred shell etc., as well as group membership for authorization (group "ops", group "wmf", various projects etc. from which various permissions are derived, such as Gerrit +2s). We also *authenticate* users via LDAP but it's not necessary that we do so (and, in fact, for many users we also rely on HOTP for 2-factor); authn/authz/identity are not necessarily tied in together, in concept.

It's not clear to me how Phabricator will handle things such as group membership when using OpenID/SUL (e.g permission to the security bug queue, +2/merge permissions). Will this information be kept separately in Phabricator's database? If so, that seems like a setback compared to Gerrit, as we won't able to manage identity in a central place and e.g. revoke all privileged permissions when someone's account gets revoked.

Finally, I think we need our overall strategy on authentication methods should include UX properties: what's the path that we're offering to newcomers to become technical contributors? How do they upgrade from Wikimedia projects user to contributing?

laner wrote on 2014-06-12 17:36:55 (UTC)

It would make me a little sad to see developer accounts move to a system that isn't sync'd with Labs by default, since Labs was the reason that developers had the ability to self-register to begin with. It also makes it less likely that people will adopt Labs, since there would be an extra barrier to entry.

It would take a bit of effort, but there's no reason Wikitech needs to use LDAP for authentication. The LDAP authentication extension can be used as a library that could automatically create LDAP accounts when a user is created. It's important, however, that keystone is taken into account.

Keystone is used for OpenStack authorization. OpenStackManager authenticates to keystone on behalf of a user and obtains a short-lived token. That token lasts for the length of a Wikitech long-lived session, which is 1 week. It's necessary for users to occasionally re-auth to get access to OpenStack again.

I believe Keystone has OAuth support, and we could add OpenID support for keystone via Apache's OpenID module. When a user creates an account on Wikitech we could have it also link the account with Keystone. Both Wikitech and Keystone could be changed to use WIkimedia as a provider.

Of course, this assumes we have OpenID, which keeps getting punted on.

mattflaschen wrote on 2014-06-12 20:20:47 (UTC)

In T338#24, @Qgil wrote:

In this scenario, if SUL is down, can users still login with their LDAP credentials?

To address the "SUL is down" issue, could we require SUL for registration, but allow people to also set up direct username/password access (it's definitely possible to have both; that's how my account is currently setup)? We could require people with ssh access to production (which includes all deployers) to set up direct username/password access to Phabricator (it would be optional for everyone else), which I think would allow deployers to work on Phabricator with SUL login down.

csteipp wrote on 2014-06-12 20:56:21 (UTC)

In T338#29, @mattflaschen wrote:

In T338#24, @Qgil wrote:

In this scenario, if SUL is down, can users still login with their LDAP credentials?

To address the "SUL is down" issue, could we require SUL for registration, but allow people to also set up direct username/password access (it's definitely possible to have both; that's how my account is currently setup)? We could require people with ssh access to production (which includes all deployers) to set up direct username/password access to Phabricator (it would be optional for everyone else), which I think would allow deployers to work on Phabricator with SUL login down.

@mattflaschen, see my previous comments about why we want ldap instead of local passwords

aklapper wrote on 2014-07-14 13:58:12 (UTC)

In T338#24, @Qgil wrote:

This is relevant to Day 1. Our goal is to replicate the setup we have in Bugzilla. Is there any connection between permissions for Bugzilla security bugs and LDAP?

No. Access to Bugzilla security bugs requires being a member of the "security" user group in Bugzilla, and membership is set manually in Bugzilla. No relation to LDAP.

(And in the meantime, SUL has been up for testing - T314.)

Rush wrote on 2014-07-16 17:27:53 (UTC)

Final thoughts:

LDAP and SUL will be enabled

I have confirmed LDAP works as an auth provider, SUL is working here http://legalpad.wikimedia.org/

Rush wrote on 2014-07-17 20:37:13 (UTC)

In T338#32, @Rush wrote:

Final thoughts:

LDAP and SUL will be enabled

I have confirmed LDAP works as an auth provider, SUL is working here http://legalpad.wikimedia.org/

if no further comments I am going to resolve this conversation tomorrow

jkrauska wrote on 2014-07-17 20:56:22 (UTC)

Can we establish which takes priority?

With both LDAP and SUL be enabled at the same time?

Will the usernames collide?

What will the 'forget my password' flow do in this case?

Trying to tease out some of the details here beyond just 'both work as auth providers'.

mmodell wrote on 2014-07-17 21:07:07 (UTC)

@JKrauska,

Phabricator has it's own user name, you link your phabricator account to one or more external auth providers. usernames cannot collide. Neither auth provider takes precedence, you can choose to log in with one or the other. You don't use "forgot my password" with the external authentication providers.

aklapper wrote on 2014-08-12 09:04:48 (UTC)

Looks like #32 summarized this; wondering if there is anything left to do here (@Rush?) or if the "decide" part in the task summary is decided.

Rush wrote on 2014-08-12 16:15:22 (UTC)

@Aklapper, resolving then as technical implementation minutia should be elsewhere

aklapper wrote on 2014-08-12 17:23:38 (UTC)

But is there any technical implementation minutia left? If so, separating that out in a ticket (and mentioning its number here) is welcome indeed...

importing issue status