Extension:OpenID Connect

The OpenID Connect extension extends the PluggableAuth extension to provide authentication using OpenID Connect.

Special thanks to jumbojett for the OpenID Connect PHP library used by this extension.

Installation
This extension requires PluggableAuth to be installed first. It also requires the OpenID Connect PHP library, which may be installed using composer.

Install Dependencies
Add the line  to the "composer.local.json" file in the root directory of your wiki, e.g.

Then run  in the root directory of your wiki. This will install any dependencies (i.e. the jumbojett OpenID Connect PHP library).

Configuration parameters
Most configuration for OpenID Connect is handled by a file found at  on the provider's domain. This contains most of the settings that are needed to handle authentication.

When configuring the identity provider, it will ask for a redirect URL or callback URL. Use the full URL to the Special:PluggableAuthLogin page for that value.

A simple example of the  configuration for a single issuer is as follows:

An example of the  configuration for multiple issuers is as follows:

Example: Google as an Issuer

 * 1) Using the Google Developer Console create a project.
 * 2) Click on the project, click on the hamburger menu (three horizontal lines in the top left), and click on   on the menu.
 * 3) Click the   button and select  . Fill in the consent screen information and save.
 * 4) Fill in the full URL of the Special:PluggableAuthLogin page of your wiki in.
 * 5) Click.
 * 6) Note the   and   that are assigned.

The Google issuer is now configured. Add the corresponding configuration to your LocalSettings.php file, filling in the  and   fields with the values assigned above.

You may also assign values for,  ,   and.

Example: Using it against Azure ADFS
Three parameters are required to use this extension to authenticate against Azure ADFS: a tenant id, a client id, and a secret.

Example: Using it against Keycloak
Assumptions:
 * Your Keycloak realm name is acme
 * Your Keycloak URL and Port is  https://keycloak.local:8080 
 * Your Keycloak Client ID is set to mediawiki
 * Your auto-genertated client secret is 12345

Troubleshooting:
 * If you´re running into trouble, like "The provider {$param} could not be fetched. Make sure your provider has a well known configuration available.", your URI is wrong. You can test the corretness by calling  https://keycloak.local:8080/auth/realms/acme/.well-known/openid-configuration  in your browser. If you get back a long JSON, the path is correct.
 * Make sure the redirect uri provided by this OIDC plugin is set valid for your keycloak-server under acme -> Clients -> mediawiki -> Settings -> valid redirect uris . For testing purposes you can add a wildcard "*".

Example: Using it with Okta
As of the date this example was written, a bug exists in the OpenID Connect PHP library which causes stricter OIDC providers like Okta to reject certain requests. This should be resolved in the future when the library is updated to incorporate the change. The solution is to add a single line of code to $MEDIAWIKI_ROOT/extensions/OpenIDConnect/vendor/jumbojett/openid-connect-php/src/OpenIDConnectClient.php as follows: right below: simply add:

To authenticate your users against Okta, you must first create a new OIDC app in your Okta org and assign it to the relevant users/groups, etc.

Okta OIDC app settings
Allowed grant types: (all) Login redirect URIs: the full URL to Special:PluggableAuthLogin, e.g. https://www.example.com/wiki/index.php/Special:PluggableAuthLogin Login flow: "Redirect to app to initiate login (OIDC compliant)" Initiate login URI: the full URL to Special:UserLogin, e.g. https://www.example.com/wiki/index.php/Special:UserLogin

Extension settings
You must specify the openid, profile, and email scopes to communicate with Okta. If you omit the appropriate scopes, Okta will gladly authenticate your users but will not return any useful claims.

Auto-creating users
If you want to take advantage of MediaWiki's user auto-creation (e.g. ), be aware that Okta's preferred_username claims take the format of an email address.

If you do not want your users to have an @ character in their usernames (this is forbidden by MediaWiki by default), you will need to specify an alternative claim to use via the 'preferred_username' key in your $wgOpenIDConnect_Config.

Allowing @ in usernames may break your wiki's Interwiki compatibility (if you rely on that). To allow the use of the @ character, just set  and   in LocalSettings.php.

Release Notes

 * Version 5.2
 * Fixed bug with migrated initial lowercase usernames (T249630)
 * Version 5.2
 * Added optional configuration options for disabling the verification of hostnames and certificates, for use in development environments with self-issued certificates
 * Version 5.1
 * Added generation of full redirect URL so OpenID Connect PHP library doesn't have to guess, which occasionally it didn't have enough information to do accurately
 * Version 5.0
 * Moved subject and issuer columns from user table to openid_connect table (requires database update)
 * Added support for Postgres
 * Version 4.1
 * Added namespace for library class
 * Version 4.0
 * Added optional error message to authenticate
 * Bumped version number to synchronize with PluggableAuth and SimpleSAMLphp extensions
 * Version 2.3
 * Fixed whitelist implementation
 * Changes migration flags to allow migration by email address in addition to migration by user name
 * Version 2.2
 * Fixes related to PluggableAuth MediaWIki 1.27 upgrade
 * Array coding conventions
 * Version 2.1
 * Update to MediaWiki 1.27 session management
 * Added default values for configuration variables to extension.json
 * Version 2.0
 * Updated extension registration
 * Changed configuration variables to use "wg" prefix
 * Added composer.json to get OpenID Connect library using composer
 * Version 1.2
 * Added ability to specify auth params and added support for table prefixes
 * Version 1.1
 * Added support for Google
 * Version 1.0
 * Initial version

Known Bugs

 * Wikis that use URLs of the form  (i.e. having the page title provided as a query parameter) will not be redirected correctly to complete the authentication flow. Instead, URLs must be of the form , which can be accomplished by using short URLs or by setting $wgArticlePath appropriately.
 * This extension may not work correctly with  (see T147161).
 * This extension does not work on non-standard ports unless you manually update the underlying Openid connect client, see: https://github.com/jumbojett/OpenID-Connect-PHP/issues/58. Issue also applies when to other webserver than IIS.