Thanks for the input. As noted, I can't use server variable REMOTE_USER because I'm on a physically different server than where the main site's http auth occurs. So I have to rely on the domain cookie, which stores the username for the main site, that is set by said main site.

So I guess my question is, should there be any inherent problems with trying to assign the username using wiki's external authentication from a cookie, as opposed to REMOTE_USER or LDAP, etc?

-----Original Message----- From: mediawiki-l-bounces@Wikimedia.org [mailto:mediawiki-l-bounces@Wikimedia.org] On Behalf Of Domas Mituzas Sent: Sunday, January 08, 2006 4:59 PM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] Authentication using existing domain cookie

Hi Justin,

The main site does log users in, and stores their information in a domain-wide cookie. However, to my knowledge, since the sites sit on two physically separate servers, I cannot use the REMOTE_USER authentication hack that is available on mediawiki.org.

So basically, I'm looking for a way for Mediawiki to take the username that is available in the domain-wide cookie and authenticate using that. Has anyone seen an implementation like that or know where I can find out how to do that?

HEAD and 1.5 have ExternalAuth hook, which allows to bind external authentication methods, this is example Auth class I've written as an example (of course, more sophisticated methods can be used..):

--Domas

<?

global $wgHooks;

$wgHooks['AutoAuthenticate'][] = 'AuthServerMagic';

function AuthServerMagic(&$user) {

if ($_SERVER["REMOTE_USER"] == "") { return new User(); }

$user = User::newFromName( $_SERVER["REMOTE_USER"] ); if ( $user->getID() == 0 ) { $user->addToDatabase(); $user->setToken(); } else { /* Should cache some day, I guess :) */ $user->loadFromDatabase(); } return true; }

?>

_______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l

You have to protect against three kinds of attacks (that is, attempts to login without proper authentication in your main server):

1) forged cookies (plain text cookies are a snap to create)

2) tampered cookies (e.g., taking a valid cookie for "user=jones" and changing it to "user=smith".

3) replayed cookies (e.g., "snooping" a cookie generated by a valid login and re-using it later.

To protect against these attacks, your domain-wide cookie should have some kind of authentication stamp. We do an MD5 hash of the username, a timestamp, and a shared secret (shared by the servers that are 'in the club' and no-one else). So our cookie* is created by the authentication server as:

user=jones;time=999999999;MAC=7E848A98.....[more hex digits]

Where the "message authentication code" (MAC) is the MD5 hash referred to above.

When the cookie is received by the wiki server, it is accepted only if:

1) the user, time, and shared secret, when hashed, give the same MAC

2) the timestamp is less than [some timeout number] seconds old.

This protects well against forged or tampered cookies, and protects somewhat against replay attacks (protection is better when the timeout is shorter).

HTH,

-- Joshua

* In our case, it's not really a cookie, the information is passed in a POST, but the principle is the same.

On 1/10/06 1:18 PM, "Domas Mituzas" midom.lists@gmail.com wrote:

Hi Justin,

...

So I guess my question is, should there be any inherent problems with trying to assign the username using wiki's external authentication from a cookie, as opposed to REMOTE_USER or LDAP, etc?

On deployment for which I wrote this code we really use domain-wide cookie instead of REMOTE_USER. Just make sure that user can't provide invalid cookies.

Domas _______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l