Release status: stable
|Implementation||User identity, Hook|
|Description||Automatically logs-in users if they are already authenticated by a remote source (e.g. environment variable
|Latest version||2.1.0 (2018-07-24)|
|License||GNU General Public License 2.0 or later|
|Translate the Auth remoteuser extension|
|Check usage and version matrix.|
|Issues||Open tasks · Report a bug|
The Auth remoteuser extension automatically logs-in users if they are already authenticated by an arbitrary remote source. The extension maps the given remote user name to an existing user name in the local wiki database (or creates it first if it has the permissions to do so). The external source takes total responsibility in authenticating that user.
This allows integration with the web server's built-in authentication system (for example via the
REMOTE_USER environment variable, which is set through HTTP-Auth, LDAP, CAS, PAM, etc.) or any other type of external authentication (SSL client auth, user accounts provided by different forum software, etc.).
- Download and place the file(s) in a directory called
Take account of MediaWikis global permissions for account creation (
autocreateaccount) inside your
LocalSettings.php. At least one of them must be
true for anonymous users to let this extension create accounts for users as of yet unknown to the wiki database. If you set this to
false, then automatic login works only for users who have a wiki account already.
// The extension can create accounts, because all anonymous users can. $wgGroupPermissions['*']['createaccount'] = true;
// If account creation by anonymous users is forbidden, then allow // it to be created automatically (by the extension). $wgGroupPermissions['*']['createaccount'] = false; $wgGroupPermissions['*']['autocreateaccount'] = true;
// Only login users automatically if known to the wiki already. $wgGroupPermissions['*']['createaccount'] = false; $wgGroupPermissions['*']['autocreateaccount'] = false;
Add some of the following global variables to your
LocalSettings.php to adjust the extensions behaviour to your specific needs. Default values for each global are marked with the "
// default" comment in the examples section.
|global||description & examples|
||Set the name(s) to use for mapping into the local wiki user database. This can either be a simple |
||This extension comes with predefined remote user name filters (which are utilizing the provided hook). If you want to replace something, set an array of search and replacement patterns to the following configuration variable (Each pattern can be a regular expression in PCRE syntax too):
||If you want to prevent some names from being logged in automatically, blacklist them with the following filter. It accepts a list of names, where each name can also be a regular expression in PCRE syntax:
||The opposite of the |
||When you have further user information available in your environment, which can be tied to a created user, for example email address or real name, then use one of the following configuration variables. Either |
You can specify an anonymous function for the values too. These closures getting called when the actual value is needed, and not when it is declared inside your
Take the following as an example in which a cost-intensive function (in a timely manner) is getting executed only once per user and not on every request:
||You can replace URLs in MediaWiki, if your remote source is better suited for handling specific behaviour. For example by default no automatically logged-in user is allowed to logout (because he will be logged-in automatically again with the next request). But maybe your remote source should handle that logout (so that with the next request there isn't a remote user name provided anymore to this extension). Set an appropriate URL to one of the following keys of the associative array |
||By default this extension mimics the behaviour of |
||As an immutable SessionProvider (see |
||If you are using other SessionProvider extensions besides this one, you have to specify their significance by using an ascending priority:
You can still use all legacy parameters from versions prior
v2.0.0, but their usage is deprecated in favour of the new parameters:
$wgAuthRemoteuserAuthz = true; /* Your own authorization test */ $wgAuthRemoteuserName = $_SERVER["AUTHENTICATE_CN"]; /* User's name */ $wgAuthRemoteuserMail = $_SERVER["AUTHENTICATE_MAIL"]; /* User's Mail */ $wgAuthRemoteuserNotify = false; /* Do not send mail notifications */ $wgAuthRemoteuserDomain = "NETBIOSDOMAIN"; /* Remove NETBIOSDOMAIN\ from the beginning or @NETBIOSDOMAIN at the end of a IWA username */ /* User's mail domain to append to the user name to make their email address */ $wgAuthRemoteuserMailDomain = "example.com";
When you need to process your remote user name before it can be used as an identifier into the wiki user list, for example to strip a Kerberos principal from the end, replacing invalid characters, or blacklisting some names, use the hook
AuthRemoteuserFilterUserName provided by this extension. Just have a look at MediaWikis Hook documentation on how to register additional functions to this hook. It provides as first parameter the remote user name by reference to the hook function. If the function returns
false, the remote user name will be ignored for automatic login. (See parameters
$wgAuthRemoteuserUserNameWhitelistFilter for predefined filters which utilizing this hook.)
Configuring different remote sourcesEdit
This environment variable can be set by many different authentication systems and the configuration of these is heavily dependent on which one you are using. You can always use
phpinfo(); to check the contents of
REMOTE_USER and to troubleshoot your setup. What follows are examples of different webserver environments and how to put a username into this environment variable.
Consult the Apache documentation for details. You can use
mod_auth_vas4 or any other authentication module that utilizes
REMOTE_USER. Once you have verified that the
REMOTE_USER environment variable is being set to the proper username, continue with installation/configuration of the extension. Some examples:
- For simple HTTP authentication add this
AuthType Digest AuthName Wiki AuthUserFile /etc/passwd-apache Require valid-user
REMOTE_USERenvironment variable is getting evaluated by default from the extension, so the following code is all you need in your
wfLoadExtension( 'Auth_remoteuser' );
- Setup HTTP SPNEGO with Vintella/Quest Authentication Services for your heterogeneous network, using
AuthType VAS4 AuthVasRemoteUserMap default AuthVasUseBasic On AuthName Wiki Require valid-user
- Now the
REMOTE_USERenvironment variable contains the full principal name, so remove the realm from the username inside your
wfLoadExtension( 'Auth_remoteuser' ); $wgAuthRemoteuserUserNameReplaceFilter = [ '@INTRA.EXAMPLE.COM$' => '' ];
Kerberos SSO ADEdit
To install & enable them in Devuan:
apt install libapache2-mod-auth-kerb a2enmod authnz_ldap
Configure Kerberos in the OS (long story short):
- Join to AD domain:
- realm join corp.ds.company.net -U domain_user_with_rights_to_join --computer-ou="use dsquery computer in windows cmd domain joined machine to get the value" --verbose
- Generate keytab on Windows AD server cmd:
- ktpass -princ HTTP/en.mediawiki.company.net@CORP.DS.COMPANY.NET -mapuser mediawiki_windows_domain_user@CORP.DS.COMPANY.NET -pass mediawiki_windows_domain_user_secret_password -crypto all -ptype KRB5_NT_PRINCIPAL -out C:\Temp\en-mediawiki.keytab
- setspn -A HTTP/en.mediawiki.company.net@CORP.DS.COMPANY.NET mediawiki_windows_domain_user@CORP.DS.COMPANY.NET
Apache con file:
AuthType Kerberos Krb5Keytab /path/to/your/keytab_file.keytab KrbServiceName Any KrbLocalUserMapping On AuthLDAPBindDN "user_name_to_authenticate_to_LDAP_server" AuthLDAPBindPassword "password_for_the_user_from_above" AuthLDAPURL "http://ldap_server_url/DC=CORP,DC=DS,DC=COMPANY,DC=NET?sAMAccountName,mail,displayName?sub?(objectClass=*)" Require ldap-attribute attribute="value"
It is required to use LDAP authorization together with Kerberos SSO if you want to get user information (email, real name) from AD.
The info from LDAP must be published to AUTHORIZE_ environment variables, so make sure you use it, not AUTHENTICATE_ in LocalSettings.php.
Using ldap-group did not publish environment variables for me, using ldap-attribute did (a bug in apache?).
Depending on your version of Internet Information Services (IIS) Manager, your navigation may be slightly different. The instructions below are specified for a corporate server running IIS v7.5 on Windows Server 2008 R2 Enterprise. (Trust me, I wanted Linux and Apache but IT wont allow it)
To enable simple authentication navigate to the following paths.
- (Server Name) > Sites > Default Web Site
- From "Features View" double click, "Authentication"
- Disable - "Anonymous Authentication"
- Enable - "Windows Authentication" (HTTP 401 Challenge)
This extension gets managed as a project on Phabricator. There you can see a list of all known and still open issues. If there is no open task related to the problem/error you've encountered, then have a look on howto report errors.
Read the MediaWiki manual on debugging or take the following as a start:
- Enable logging by setting the
LocalSettings.phpto a file to which your webserver has write access to.
- Request your MediaWiki installation like you did when the error occurred. This extension logs all its output to the
[session]channel into your log file.
- Inspect the log file and search for all lines starting with
- Decide if you can fix the error by yourself or if it is related to how this extension works. If so, then have a look on howto report errors.
Assemble relevant debugging information (relevant in terms of others can reproduce the error) and:
- Either read MediaWiki's howto on reporting bugs, or
- create a new task on this extensions Phabricator project (if you have a Phabricator account), or
- write an email to members of the Phabricator project, or
- use this extensions talk page.
You're welcome to enhance this extension. Read How_to_become_a_MediaWiki_hacker, grab one of the open issues from the Phabricator project (or create a new task) and upload your patch to this extensions Gerrit project. There you can also see:
- a list of current extension maintainers with write access (if you have a Gerrit account),
- a list of uploaded patch sets.
Just use the same workflow as with error reporting.