Extension talk:SSL authentication

» Archive (early 2011 and earlier)

hiding logout button slightly broken with MW-1.19

I've just installed mediawiki-1.19.0beta1 and added the 1.19 version of SSLAuthPlugin.php. End result: working well except that the logout button has been replaced with "AMPlt;0AMPgt;" (I replaced the ampersands with AMP as I don't know what would happen to them in this editor).

Must be a slight bug in something? Also, MW still asks to confirm the email address - can the code also take that into account? i.e. a cert with an email address should be treated as validated?

Thanks - this was VERY easy to get up and running!

Jason

--Paran7 (talk) 21:52, 23 March 2012 (UTC)

The logout link problem exists with 1.18 as well. The problem is that the logout url is set to null rather than being removed. The following patch fixed the problem for me:

--- a/SSLAuthPlugin.php
+++ b/SSLAuthPlugin.php
@@ -227,7 +227,7 @@ function SSLAuthSetup() {
  
 /* No logout link in MW */
 function NoLogout(&$personal_urls, $title) {
-        $personal_urls['logout'] = null;
+        unset($personal_urls['logout']);
         return true;
 }

Would be great if somebody else could test this. If it works then I guess I should just change the code in the main article.

how to map USER_PRINCIPAL_NAME under X509_EXTENSION with AD - UserPrincipalName attribute

I am able to implement this extension. After that, I need to map USER_PRINCIPAL_NAME to AD UserPrincipalName to get more data back from Active Directory. Do you have some example code I could reference?

I have been searched about this issues for a while ===========

only to find the PHP Bug #60388 about openssl_x509_parse extensions=>subjectAltName. If you are able to find any workaround, I would love to learn how..

Problems with SSLRequire apache configuration and email/realname import

Hi,

I´m new in mediawiki, and i´ve used this extension for client register/autentication but i found several problems in configuration:

_First, the line "SSLRequire  %{SSL_CLIENT_S_DN} =~ m/.*serialNumber=<personnumber>$/" in apache config doesn´t work and i have replaced by tree lines "SSLVerifyClient require/SSLVerifyDepth 2/SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"" and works well, but i don´t understand why doesn´t work the first one and if this configuration is optimal for the extension.

_Second, when i login with my client certificate (which has my own CA), the user is created fine, but the email and the realname aren´t written to the user´s profile.SOLVED, i´ve set ssl_map_info=true

My version of mediawiki is 1.20 and i´ve used "SSLAuthPlugin.php (MW 1.20)"

Can anyone help me with this problems?

Thanks in advance,

Carlos

(apache config) SSLVerifyClient=optional and no user cert present causes (harmless) errors on viewed page

I've discovered that when a user certificate is not presented (when SSLVerifyClient=optional, otherwise SSLVerifyClient=off should never have this extension) then three errors are dumped to any viewed page corresponding to the certificate information extraction lines in LocalSettings.php.

I've added a test for each to determine if the value is not set before using the values.

Liamdennehy (talk) 17:17, 27 July 2014 (UTC)

Compatibility with MW 1.23

When trying to use version 1.1.6 under MediaWiki 1.23, I get the following error:

 PHP Fatal error:  Cannot access protected property LoginForm::$mRemember in /usr/share/mediawiki123/extensions/SSLAuthPlugin.php on line 304

This is the line

 $lf->mRemember = false;

just before calling $lf->initUser(). The variable is marked as protected in MediaWiki 1.23. It seems to be the checkbos "Keep me logged in" on the login form. Just removing that line seems to work, and so far I haven't seen any ill issues from doing so.

--NscBellman (talk) 15:15, 17 August 2015 (UTC)

Correcting Compatibility with MW 1.25

After updating from MW 1.23.4 (due to a performance bug) to 1.25.3 I noticed our users were randomly loosing access. They were PKI authenticating, but those who were frequent visitors retained access, while those less frequent visitors observed HTTP Error 500. Debug data from wiki/PHP/mySQL all indicated query to insert new users was issued, but also indicated reportExpectationViolation that (writes <= 0). The database row was confirmed non-existent, and no error was logged by MySQL. Ultimately, I found references via error log levels that pointed via the traceback that the User class methods for user->saveSettings() was throwing an exception (line 3621) while calling mPassword->toString(). This was also failing in user->addtoDatabase(). The current version of MW requires the password set in SSLAuthPlugin not be a string to avoid exceptions, and ultimately SQL insertion failure without error. The following compatibility changes were made to the existing 1.1.6. The password comparison conditional should be revisited, but this solution restored PKI authentication. I'm new to this wiki/sharing thing (I install/administer/troubleshoot, not really much time to use), so I'll post here, and update the extension page if I can... later.

Source: SSLAuthPlugin.php Modify the following string password assignment in UpdateUser

//Should do a compare here, as passwords are hashes now.  Will come back.
if($user->mPassword != "nologin") {
    //$user->mPassword = "nologin";
    $user->setPassword(null); //can also pass a string here.
    $user->saveSettings();
}

Note - User.php saveSettings() calls mPassword->toString(). mPassword may not be a string according to MW 1.25

Comment the following override to allow password changes

//function allowPasswordChange() {
//    return false;
//}

Note - if Wiki 1.25.3 User.php requires password string operations which can only be performed on non-strings, we must allow password setting. allowPasswordChange returns true by default in AuthPlugin.php so I've commented the override below.

Comment the following override to allow to allow setPassword to function

//function setPassword( $user, $password ) {
//    return false;
//}

Note - comment the override below to allow User.php setPassword() to function for new account password creation

--JMBConsulting (talk) 07:21, 2 December 2015 (UTC)