Topic on Extension talk:OpenID Connect

Feature requested: https://phabricator.wikimedia.org/T339311

Hi, just wanted to say thanks for writing this extension. I thought I'd share a couple tidbits for configuring this to use Okta as an identity provider.

I edited the OpenID Connect extension's composer.json to use jumbojett/openid-connect-php 0.9.0 instead of 0.5.0, but as far as I can tell, there weren't any changes between 0.5.0 and 0.9.0 relevant to anything I encountered.

Okta will not honor requests that contain client credentials in the header and post data at the same time, so after authenticating with Okta successfully, the OpenID Connect extension would error out and I'd see a red "Fatal error authenticating user" or similar message. This is an upstream issue with jumbojett/open-id-client-php, and it turns out there's already a pull request for the fix but it hasn't been approved yet. I can't post a link here for some reason, but it's pull request 208 for the project on github - just paste unset($token_params['client_id']); right below or above the existing unset($token_params['client_secret']); inside of extensions/OpenIDConnect/vendor/jumbojett/openid-connect-php/src/OpenIDConnectClient.php

You'll know this is your issue if you see errors in your Okta system log; or if you have debug logging enabled in MediaWiki, you'll see this in the log: [OpenID Connect] Jumbojett\OpenIDConnectClientException: Cannot supply multiple client credentials. Use one of the following: credentials in the Authorization header, credentials in the post body, or a client_assertion in the post body.

The other important thing to note about using this extension with Okta is that Okta will not provide any useful claims unless you explicitly request the correct scopes. If you don't specify scopes, the OpenID Connect extension will receive null/empty values for Real Name and Email, so if MediaWiki is already configured to auto-create users, you'll be logged in as "User".

To summarize, once the upstream jumbojett/open-id-client-php issue is resolved (just paste in the single line of code from the above github pull request), your $wgOpenIDConnect_Config in LocalSettings.php should look like this to work with Okta:

$wgOpenIDConnect_Config['hxxxx://foo.okta.com'] = [

    'name' => 'Okta',

       'clientID' => '(paste from the OIDC app you created in Okta)',

       'clientsecret' => '(paste from the OIDC app you created in Okta)',

       'scope' => [ 'profile', 'email' ]

  ];

Thank you so much for the feedback! Please fee free to add an Example section on the extension page with the information about configuring the extension to work with Okta.

Will do, thanks.

Would it be a good idea to check for null and throw a warning if the extension receives a null 'name' or 'email' claim from the identity provider? I just wonder if there are any ill effects or edge cases where passing along a null/empty claim that the extension received from the upstream jumbojett OIDC client library would cause issues. It might also circumvent the issue @Natlan21 mentioned, and I also experienced, where an existing user's first successful authentication results in being named "User" in the absence of a non-null/empty claim.

One more thing I noticed... when I enable auto-creation of users who come in through PluggableAuth, and the OIDC extension passes along the new user's username for creation, it is rejected because the 'preferred_username' claim from Okta takes the form of an email address (pgrungi@example.com) and MediaWiki doesn't like the @ symbol in usernames by default.

I tried to overcome this by setting $wgOpenIDConnect_UseEmailNameAsUserName = true; so new users would be created as 'Pgrungi' instead of 'Pgrungi@example.com', but it seems that the OIDC extension prefers to honor the claim it received even if that setting is enabled. It makes sense -- you explained in the option description that the setting is used if no preferred_username is specified. Unfortunately I don't have a way to change Okta's preferred_username claim format, and I don't have a custom claim I can send in the shorter, @-less format.

In the end, my workaround was to set $wgInvalidUsernameCharacters = ''; so the @ would no longer be forbidden. In my environment this is a reasonable workaround, but from what I read elsewhere, it potentially breaks Interwiki functionality, so it may not work for others.

Would you consider a new $wgOpenIDConnect_IgnorePreferredNameClaim option (set to false by default) that enforces using the $wgOpenIDConnect_UseEmailNameAsUserName format, even if the identity provider sends a non-null 'preferred_username' claim?

Thanks for the suggestions! Could you please add feature request tasks in Phabricator for these? Thanks!