Core Platform Team/Initiatives/Adding Multiple Identity Providers to PluggableAuth

From mediawiki.org
Jump to navigation Jump to search

Initiative Vision

< Initiatives

Vision:
  • Support login from multiple identity providers in a single wiki
Stakeholder(s):
  • Wiki admins who need to support authentication from off-wiki identity providers (e.g. admins of third-party Wikibase instances)
  • Wiki users who wish to be able to login using existing credentials from other identity providers
Problem:
  • (Admins) Configure wiki with one or more off-wiki identity providers
  • (Admin) Configure username mapping for multiple providers
  • (Users) Select identity provider on login
Solution:
  • Add support for multiple authentication providers to PluggableAuth.
  • Remove support for multiple authentication providers from OpenID Connect (support migration).
  • Update core to support identity provider selection. (optional)
  • Update core to better support passwordless identity providers. (optional)
Aligned Goals:
  • Enhance Production Code Ownership, Support & Accountability for the Platform Engineering Team
Success Metrics:
  • User is presented with a selection of identity providers to choose between and is able to successfully login to the wiki with any of them.

Initiative Description

< Initiatives

Summary

Support login from multiple identity providers in a single wiki

Significance and Motivation

Feature requested for third-party Wikibase installations and other third-party wikis

Outcomes
  • MediaWiki third party deployments, including Wikibase, can support authentication from multiple enterprise sources
  • Better support for different authentication models and exercise of alternate code paths. This makes things better for our own authentication approaches, such as CentralAuth.
  • Increases the familiarity on Platform Engineering Team with the authentication code that we are responsible for and could be a good gateway task to CentralAuth work.
Baseline Metrics

PluggableAuth only supports a single authentication provider at a time, and most authentication providers only support a single identity provider.

Target Metrics

PluggableAuth supports multiple simultaneous authentication providers

Stakeholders
  • Wiki admins who need to support authentication from off-wiki identity providers (e.g. admins of third-party Wikibase instances)
  • Wiki users who wish to be able to login using existing credentials from other identity providers
Known Dependencies/Blockers

None given

https://www.mediawiki.org/wiki/Extension:PluggableAuth:

The PluggableAuth extension provides a framework for creating authentication and authorization extensions.

Authentication is the process of proving that a user is who they say they are. This may be done, for example, by providing a username and password or some token or biometric. PluggableAuth supports the following authentication extensions:

Authorization is the process of determining whether a particular authenticated user should have access to a particular resource - in this case a wiki. This may be done, for example, by checking a list of authorized email addresses or checking values of user attributes provided by an identity server. PluggableAuth supports the following authorization plugins:

Background:

The PluggableAuth extension and associated authentication and authorization plugins are widely used in the third-party MediaWiki community to support authentication with enterprise and public identity providers. A design principle for PluggableAuth is that it must continue to be usable across the wide range of current use cases from Google authentication to Azure authentication to SAML authentication and more.

One feature that has been much requested recently is support on a single wiki for multiple identity providers. This is similar to going to many modern web sites and being offered the choice of authenticating with Google, Facebook, Twitter, etc. The OpenID Connect plugin currently supports this feature, but only for providers that support that protocol. There has been a request from third-party Wikibase users as well as Hallo Welt to make this feature available for all PluggableAuth plugins. For example, see task T258726.

Requirements:

  • design new config to support multiple providers
  • add unit tests to PluggableAuth including dummy test providers
  • design special page for selecting providers (either an enhancement to Special:UserLogin or a separate special page as is done for OpenIDConnect - this may require core changes, but perhaps those could be deferred to a separate, later project)
  • implement provider chooser
  • retrofit OpenIDConnect to use PluggableAuth provider chooser rather than its own
  • add support to SimpleSAMLphp (may delegate to Hallo Welt)
  • code review and acceptance testing by WMDE and Hallo Welt

Time Estimate:

  • 2 developers for 4 weeks

Note:

PluggableAuth login is intended for third-party MediaWiki and Wikibase wikis. It is NOT being suggested for use on Wikimedia projects. Among many other factors, there would be too much community opposition to Wikimedia accounts being linked to and known by non-Wikimedia identity providers. That being said, it is possible that some internal wikis may choose to use it. For example, it is currently used on https://wikifarm.wmflabs.org/cpt/index.php/Special:Userlogin to support authentication using Wikimedia GSuite credentials.



Subpages


Poll

Team members are invited to voice support or opposition, and give their reasoning.

  • Support Better support for different authentication models and exercise of alternate code paths, and increases the familiarity on Platform Engineering Team with the authentication code that we are responsible for. CCicalese (WMF) (talk) 19:30, 30 November 2020 (UTC)[]
  • Support While the functionality proposed here isn't super important to WMF, familiarity with the authentication code is crucial in case something breaks. This project would provide an opportunity to build that familiarity. We should do it. -- DKinzler (WMF) (talk) 18:39, 2 December 2020 (UTC)[]
  • Neutral Neutral I agree that the idea has merit, but personally I have no interest in working on this. PPchelko (WMF) (talk) 19:43, 2 December 2020 (UTC)[]
  • Support Standardized auth methods are preferred. Not sure I would make this a high priority project — Preceding unsigned comment added by HKnust (WMF) (talkcontribs) 22:17, 2 December 2020
  • Support Seems like both useful functionality for third parties, and a good vehicle for exploring the authentication code. I would be happy to work on it if priorities allow. BPirkle (WMF) (talk) 15:15, 3 December 2020 (UTC)[]
  • Support Agreed with other sentiments as a great opportunity for familiarity with auth code, but not necessarily highest priority since its my understanding we should be prioritizing WMF-specific projects over community-supporting projects. But happy to help and learn about auth. NNikkhoui (WMF) (talk)
  • Support SGTM --Valerio Bozzolan (talk) 15:48, 22 March 2021 (UTC)[]

Please use the polling templates, for example:

* {{support}} I like this example!  ~~~~
* {{weak oppose}} This is not a great example example... ~~~~