Extension talk:OpenID Connect

About this board

When reporting an error, please be sure to include version information for MediaWiki and all relevant extensions as well as configuration information. Also, please turn on debug logging as described at Manual:How to debug#Logging and include the relevant portions of the debug log.

Curl error in jumbojett/openid-connect-php

7
Summary by Libresauce

SELinux was preventing httpd from communicating with the Azure endpoint on port 443, producing a curl error in the openid-connect-php client.

Libresauce (talkcontribs)

I'm trying to set up Azure Entra ID login. Right now instead of sending me to Azure I get "Fatal error authenticating user." I double-checked my providerURL and it seems to be correct. Any idea where I'm going wrong? I keep getting <abusefilter-warning-linkspam> when posting this, so I had to strip out some information.

Logs

Stack trace:

#0 /var/www/mediawiki-1.41.0/extensions/OpenIDConnect/vendor/jumbojett/openid-connect-php/src/OpenIDConnectClient.php(658): Jumbojett\OpenIDConnectClient->fetchURL()

#1 /var/www/mediawiki-1.41.0/extensions/OpenIDConnect/vendor/jumbojett/openid-connect-php/src/OpenIDConnectClient.php(634): Jumbojett\OpenIDConnectClient->getWellKnownConfigValue()

#2 /var/www/mediawiki-1.41.0/extensions/OpenIDConnect/vendor/jumbojett/openid-connect-php/src/OpenIDConnectClient.php(787): Jumbojett\OpenIDConnectClient->getProviderConfigValue()

#3 /var/www/mediawiki-1.41.0/extensions/OpenIDConnect/vendor/jumbojett/openid-connect-php/src/OpenIDConnectClient.php(447): Jumbojett\OpenIDConnectClient->requestAuthorization()

#4 /var/www/mediawiki-1.41.0/extensions/OpenIDConnect/includes/OpenIDConnect.php(229): Jumbojett\OpenIDConnectClient->authenticate()

#5 /var/www/mediawiki-1.41.0/extensions/PluggableAuth/includes/PluggableAuthLogin.php(101): MediaWiki\Extension\OpenIDConnect\OpenIDConnect->authenticate()

#6 /var/www/mediawiki-1.41.0/includes/specialpage/SpecialPage.php(727): MediaWiki\Extension\PluggableAuth\PluggableAuthLogin->execute()

#7 /var/www/mediawiki-1.41.0/includes/specialpage/SpecialPageFactory.php(1621): MediaWiki\SpecialPage\SpecialPage->run()

#8 /var/www/mediawiki-1.41.0/includes/MediaWiki.php(357): MediaWiki\SpecialPage\SpecialPageFactory->executePath()

#9 /var/www/mediawiki-1.41.0/includes/MediaWiki.php(960): MediaWiki->performRequest()

#10 /var/www/mediawiki-1.41.0/includes/MediaWiki.php(613): MediaWiki->main()

#11 /var/www/mediawiki-1.41.0/index.php(50): MediaWiki->run()

#12 /var/www/mediawiki-1.41.0/index.php(46): wfIndexMain()

#13 {main}

[PluggableAuth] Authentication failure.

[PluggableAuth] ERROR: Jumbojett\OpenIDConnectClientException: Curl error: (7) in /var/www/mediawiki-1.41.0/extensions/OpenIDConnect/vendor/jumbojett/openid-connect-php/src/OpenIDConnectClient.php:1495

Configuration

MediaWiki 1.41.0

PHP 8.1.27

PHP curl and json modules installed

MariaDB 10.5.22

jumbojett/openid-connect-php 0.9.10

Latest PluggableAuth and OpenID Connect extensions (just did git pull)

Relevant portion of LocalSettings.php

wfLoadExtension( 'PluggableAuth' );

wfLoadExtension( 'OpenIDConnect' );

$wgPluggableAuth_Config[] = [

    'plugin' => 'OpenIDConnect',

    'buttonLabelMessage' => 'Login with Entra ID',

    'data' => [

        'providerURL' => 'https://login.microsoftonline.com/930d382e-dc17-46c9-a847-e0eb41cc16f7/v2.0/',

        'clientID' => ***************************,

        'clientsecret' => '***************'

    ]

];

$wgOpenIDConnect_UseEmailNameAsUserName = true;

$wgOpenIDConnect_MigrateUsersByEmail = true;

$wgPluggableAuth_EnableLocalLogin = true;
Cindy.cicalese (talkcontribs)

Curl error 7 is "could not connect to host". Why are there <nowiki> tags in your provider URL?

Libresauce (talkcontribs)

Sorry, didn't realize those tags were in there. They're not in the actual LocalSettings.php. I confirmed that provider URL matches the OpenID Connect metadata document URL from the Azure portal, minus /.well-known/openid-configuration

Cindy.cicalese (talkcontribs)
Libresauce (talkcontribs)
Cindy.cicalese (talkcontribs)
Libresauce (talkcontribs)

Discovered it was being blocked by SELinux. setsebool -P httpd_can_network_connect 1 fixed it.

difference between using this and LDAP for authentication

1
Wikiphpnoob (talkcontribs)

i've hit a wall trying to set up authentication using LDAP and am curious which is easier to set up and maintain between the two

i have MediaWiki 1.41.0, PHP 8.3.3 on Windows Server 2016 ( i know, its old), with IIS 10

just curious what peoples thoughts are, thanks for any feedback

Reply to "difference between using this and LDAP for authentication"

switching usernames from 'RealName' to 'EmailName'

2
Dan-Dalpiaz (talkcontribs)

I had a couple questions regarding usernames:

First, I've been using $wgOpenIDConnect_UseRealNameAsUserName set to 'true' for a wiki and am wondering if the 'real name' that is provided by the issuer changes in the future, will the username in MediaWiki be updated to reflect that change?

And I'm considering changing to use the 'email name' for the username instead, but simply setting $wgOpenIDConnect_UseEmailNameAsUserName to 'true' instead of the 'real name' option doesn't seem to update the username on subsequent logins. Is there a way to do that? Thanks!

Cindy.cicalese (talkcontribs)

The username config variables are only used when the account is initially created. The username will not change automatically when the real name changes or if you switch to a different username source. You would have to use another extension (e.g. Extension:UserMerge) to manually rename the accounts.

Reply to "switching usernames from 'RealName' to 'EmailName'"

Modify the login buttons to show even longer button texts (solution presented)

1
Wikinaut (talkcontribs)
Reply to "Modify the login buttons to show even longer button texts (solution presented)"

Could not get authentication plugin instance

1
Schott.schule (talkcontribs)

I have a problem using this with PluggableAuth.

This is in my LocalSettings.php:

wfLoadExtension( 'PluggableAuth' );

wfLoadExtension( 'OpenIDConnect' );

$wgPluggableAuth_Config[] = [

    'plugin' => 'OpenIDConnect',

    'data' => [

        'providerURL' => 'URL....',

        'clientID' => client....',

        'clientsecret' => 'secret....',

        'scope' => [ 'openid', 'roster-core.readonly' ],

        'responseType' => 'code'

    ]

];

$wgGroupPermissions['*']['createaccount'] = false;

$wgGroupPermissions['*']['autocreateaccount'] = true;

$wgPluggableAuth_EnableAutoLogin = false;

$wgPluggableAuth_EnableFastLogout = true;

$wgDebugLogFile = "debug-{$wgDBname}.log";

$wgDebugLogGroups['PluggableAuth'] = "pluggableauth.log";

$wgDebugLogGroups['OpenIDConnect'] = "openidconnect.log";

$wgDebugLogGroups['http'] = 'http.log';


My Wiki only shows fatal error but in the pluggableauth.log i find the following:

2023-12-31 12:02:48 v2202311158332242983 WU8900: In execute() 2023-12-31 12:02:48 v2202311158332242983 WU8900: Getting PluggableAuth instance 2023-12-31 12:02:48 v2202311158332242983 WU8900: Could not get authentication plugin instance. 2023-12-31 12:02:49 v2202311158332242983 WU8900: ERROR: return to URL is null or empty


which indicates for me, that the error must come from PluggableAuthFactory.php line 190:

if ( $name !== null && isset( $this->pluggableAuthConfig[$name] ) ) {...}

$this->logger->debug( 'Could not get authentication plugin instance.' );

return null;


So it seems to me, that it does not detect the Config correctly, but i don't know that is wrong. I ran the php update and composer update....


Can someone provide some help for me?

Reply to "Could not get authentication plugin instance"

google oauth unconfirmed email

2
Bawolff (talkcontribs)
Cindy.cicalese (talkcontribs)

It does not do anything past what the Google identity provider provides, so out of the box it would be vulnerable. However, PluggableAuth can be extended with an authorization plugin that could do a local check to ensure that the account is valid for use.

Reply to "google oauth unconfirmed email"

rereading "preferred_username" defaults

2
Wladek92 (talkcontribs)
Cindy.cicalese (talkcontribs)

I tried to elaborate a bit on it. It isn't really a loop. The default value for 'preferred_username' really is the string 'preferred_username', which is the name of an attribute that contains the preferred username. I'm not sure if the additional words make that any clearer.

Reply to "rereading "preferred_username" defaults"

Steps to setup Openidc required

1
165.156.28.87 (talkcontribs)

Can i get the steps required to setup openidconnect with mediawiki .

Also my mediawiki user database currently has only default users , how can i automate user creation or login ?

Reply to "Steps to setup Openidc required"

Account merging failing due to case differences

1
Skillson (talkcontribs)

We've got Azure AD login working great (MW 1.40), but existing accounts are not being merged with, we *think* because the incoming email addresses have capital letters in them, but the current internal accounts do not, and the code in OpenIDConnectStore just does a direct comparison. Is it possible to for the extension to make this comparison case-insensitive?

Reply to "Account merging failing due to case differences"

How to best debug "Fatal error authenticating user."?

3
Summary by Kghbln

I such a case, regular error logging provided by MediaWiki should do the trick.

Kghbln (talkcontribs)

To me this appears to be a pretty stupid question.

Anyhow after trying to log in via Azure AD, I get this error right after starting the login process. Admittedly I nearly made it before without getting this error. However, I provided the wrong redirect URL for the app at Azure AD (wrong lang - the error is on me ;). After updating the redirect URL for the app at Azure AD, I instantly get the error message rather than going through all the login steps as before when using the wrong redirect URL. Something is in the water.

Anyhow, how do I get a meaningful error indication here? Error logging is enabled for the wiki however the error log remains silent.

Cindy.cicalese (talkcontribs)

My suggestion would have been to enable error logging, but clearly you've already done that.

You mentioned elsewhere using PluggableAuth 6.3. Are you able to try 7.0? It has many improvements.

Kghbln (talkcontribs)

Good to know that turning on logging is the way to debug best. This info already helps a bunch. I figured it might also come from Azure without logging on the wiki side.

PA 7.0 requires MW 1.39, but in the end, looking at the EOL of MW 1.35, it is probably best to move on to 1.39 and continue testing.