Authentication: Difference between revisions

Add links
From Meta, a Wikimedia project coordination wiki
Browse history interactively
← Older edit
Content deleted Content added
VisualWikitext
No edit summary
No edit summary
 
(14 intermediate revisions by 8 users not shown)
Line 1: Line 1:
:''For the help page of Two-factor authentication, click [[m:Special:MyLanguage/2FA|here]]''
* Suggestion I: [[LDAP Authentication]]
{{MovedToMediaWiki}}
: by [[User:Ryan lane|Ryan Lane]]
* Suggestion II: [[Web server Authentication]], and PHP/Pear::Auth. that solves the problem with LDAP authentication because if your webserver can LDAP/PAM whatever
: by [[User:Bill Clark|Bill Clark]]
* See also: [http://mail.wikipedia.org/pipermail/mediawiki-l/2005-February/003629.html Apache Basic Auth] for those looking to use an existing basic-auth in conjunction with MediaWiki.
----
Comments by Ryan (published with his permission) --[[User:Nyxos|Tom Gries]] [[{{SERVER}}{{localurl:Special:Emailuser|target=Nyxos}} mail]] 20:20, 4 Nov 2004 (UTC)

It seems to me that our patches are somewhat independent, and use different options in LocalSettings.php. I believe our ideas are two separate but
equally useful ones. Bill's idea is to have a webserver (which can already do authentication of various types) authenticate for the wiki, whereas my
patch will work with LDAP servers directly and can handle multiple domains simultaneously. My patch also gives the option of using the local database
as well as LDAP servers incase a user cares to use the wiki for a transition period, or does not want a user to have an account in LDAP. The use of
either patch would depend on what the end user's network (and management/system admins) allow.

If any of us can think of a good way to combine these patches, I'm all for it, but I'm truthfully somewhat ignorant on using webservers for
authentication, and the way we could merge these patches in such a way that we would have one set of options in LocalSettings.php that would allow both
methods to be used usefully.

I don't personally see a problem with having '''three''' different options for authentication though

# local database (default),
# [[Web Server authentication]] (Bill's patch), and
# [[LDAP Authentication]] (my patch),
# [[bugzilla:1360|Auto-login / Auto-account-creation by hostname for intranet MediaWikis (patch and flowchart)]] based on
## hostname detection with php: gethostbyaddr() and/or
## NTLM authentication to detect a logged-in Windows user by using NTLM HTTP Authentication, see [[en:NTLM]] and http://modntlm.sourceforge.net and http://modntlm.jamiekerwick.co.uk/

as they seem like separate ideas.

I have put some short documentation at [[LDAP_Authentication]] and I have linked to it from the roadmap.

[[User:Ryan lane|Ryan Lane]]

----

I'm interested in using mediawiki in conjunction with an external authentication source, namely, Shibboleth[http://shibboleth.internet2.edu]. This is a system which allows for distributed single-sign on between institutions and is growing in popularity in the educational sector. Something similar would be well-received in wiki-land, I expect: I for one am sick of signing in at 5-10 seperate mediawiki installations, a centralised login would be a boon.

A quick bit of thinking about what would need to be done:

(This would also be of use for other sign-on technologies such as pubcookie[http://www.pubcookie.org/]).

# Support external HTTP authentication[http://www.faqs.org/ftp/rfc/rfc2617.txt], which works roughly like this
## user accesses a URI which is defined to be access-controlled by the web server
## web server returns 401 (unauthorized), browser asks user for their credentials
## credentials returned in an ''Authorization:'' header
# There would need to be a bit of hacking around account creation: namely, explicit account creation would be disabled entirely, but if shibboleth presents an authenticated user for which mediawiki knows nothing about, it should silently fill out the default account bits for the user.
# the login challenge would need to be identifiable by a URI so that an apache <Location> header could be applied to it.

Shibboleth hooks into the web server's authentication magic and directs people off to an external source to authenticate. This external server then communicates back with shibboleth, passing information about the user (from their username to whatever else they've agreed to share). At that point, the username and other info can be provided to mediawiki via the HTTP environment variables, e.g. ''REMOTE_USER''.

(Sorry if this seems a bit unclear!)

[[User:Jdowland|Jdowland]] 13:31, 20 Jun 2005 (UTC)

:: Someone mentioned PEAR::Auth above: Note that there's also [http://pear.php.net/package-info.php?package=Auth_HTTP PEAR::Auth_HTTP] which, I think, might work in conjunction with shibboleth.

::: For this purpose (SSO in Wikis, Blogs, Forums) OpenID (http://openid.net) is a very good solution too.


----

A solution to integrate MediaWiki with external authentication systems is available at http://wiki.case.edu/CaseWiki:External_Authentication. --[[User:IndyGreg|IndyGreg]] 18:51, 29 July 2005 (UTC)

----
How to [[Auto Login via REMOTE USER |automatically login to MediaWiki based on REMOTE_USER]](authentication via apache).

----

Poor-mans external Auth (for mediawiki 1.4.7)

I choose yet-another way which is much more simpler; I have an existing LDAP Authentication Infrastructure and use Apache. By default, all our internal websites are protected with mod_auth_ldap.

A prerequisite is, that I ask people to log in with their email-address. To get the username, I split the email address (username@domain.com) and take what is before the "@" later. By that I have both username and email in my session.

If a user connects now Apache takes care of the authentication. This allows me the flexibility I need in terms of giving Access only to people with certain Attributes/Values etc.

When the wiki is started, it has the login user name (= the email address) in the Environment (REMOTE_USER).

If people only want to browse the wiki, they don't have to do anything else.

The editors have to create an account and log in. To make sure that the names of the users in the wiki are complying to what I have in LDAP, I made the Userlogin.php mostly read-only.

It is a step for the user to create the account and click on log-in, but hey, user procedures are good and keep the guys busy ;-)

With a little bit of effort, it should be possible to rewrite Mediawiki to only rely on the REMOTE_USER environment variable. But I don't have the patience and time to do that and this poor-mans' approach is quick and fits fully into my user management system.

This is what I did to Userlogin.php
<pre>
--- Userlogin.php 2005-08-11 11:02:53.000000000 +0200
+++ Userlogin.php.orig 2005-03-27 18:11:26.000000000 +0200
@@ -24,7 +24,7 @@
<tr>
<td align='right'><label for='wpName'><?php $this->msg('yourname') ?>:</label></td>
<td align='left'>
- <input tabindex='1' readonly type='text' name="wpName" id="wpName"
+ <input tabindex='1' type='text' name="wpName" id="wpName"
value="<?php $this->text('name') ?>" size='20' />
</td>
<td align='left'>
@@ -37,7 +37,7 @@
<tr>
<td align='right'><label for='wpPassword'><?php $this->msg('yourpassword') ?>:</label></td>
<td align='left'>
- <input tabindex='2' readonly type='password' name="wpPassword" id="wpPassword"
+ <input tabindex='2' type='password' name="wpPassword" id="wpPassword"
value="<?php $this->text('password') ?>" size='20' />
</td>
<td align='left'>
@@ -52,7 +52,7 @@
<tr>
<td align='right'><label for='wpRetype'><?php $this->msg('yourpasswordagain') ?>:</label></td>
<td align='left'>
- <input tabindex='5' readonly type='password' name="wpRetype" id="wpRetype"
+ <input tabindex='5' type='password' name="wpRetype" id="wpRetype"
value="<?php $this->text('retype') ?>"
size='20' />
</td>
@@ -62,7 +62,7 @@
<?php if( $this->data['useemail'] ) { ?>
<td align='right'><label for='wpEmail'><?php $this->msg('youremail') ?>:</label></td>
<td align='left'>
- <input tabindex='7' readonly type='text' name="wpEmail" id="wpEmail"
+ <input tabindex='7' type='text' name="wpEmail" id="wpEmail"
value="<?php $this->text('email') ?>" size='20' />
</td>
<?php } ?>
@@ -106,4 +106,4 @@
}
}

-?>
+?>
\ No newline at end of file
</pre>

And here the changes to SpecialUserlogin.php

<pre>
--- SpecialUserlogin.php 2005-08-11 10:55:00.000000000 +0200
+++ SpecialUserlogin.php.orig 2005-06-19 04:05:20.000000000 +0200
@@ -404,11 +404,7 @@
if ( 0 != $wgUser->getID() ) {
$this->mName = $wgUser->getName();
} else {
- //$this->mName = @$_COOKIE[$wgDBname.'UserName'];
- $this->mEmail = getenv("REMOTE_USER");
- $pieces=explode("@",getenv("REMOTE_USER"));
- $this->mName = $pieces[0];
-
+ $this->mName = @$_COOKIE[$wgDBname.'UserName'];
}
}

</pre>

Now, this applies to the Version 1.4.7 but I did it for earlier versions as well; the idea is to inject the REMOTE_USER into the Authentication logic as early as possible and avoid the user to change it by any means. Afterwards, the User DB of Mediawiki is used.

Caveat: If you create your Mediawiki with an admin user which is not in ldap, you have to modify the user db manually to be able to use the administrators functions.
As changing an account is somewhat tricky (at least if you spend no time in searching and reading the documentation), I did the following: Use phpmyadmin to access the user_rights table, delete the entry for my personal account, copy the entry for the admin account to my user_id. One of the gurus out there might have an idea on a cleaner way.

----
See also: [[Access control]]


[[Category:MediaWiki Development]]

Latest revision as of 00:56, 16 November 2021

For the help page of Two-factor authentication, click here
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Authentication&oldid=22339885"