Opened 12 years ago

Last modified 22 months ago

#165 assigned task

Wiki LDAP integration

Reported by: crschmidt Owned by: astrodog
Priority: normal Milestone:
Component: Wiki Keywords: ldap, wiki
Cc: martin, Jeff McKenna, strk, Cwillmes, sac@…, jive


MediaWiki? has an extension to support LDAP integration. It is described in the Mediawiki LDAP auth page .

The requirements to install are as follows:

  • MediaWiki? 1.6+ for current version of the plugin (I will no longer be backporting to the 1.5 series)
  • PHP must be compiled with LDAP support for any functionality at all
  • PHP must be compiled with SSL support if you wish to authenticate over SSL (HIGHLY Recommended!!)
    • Your server must trust the LDAP server's Certificate's Root CA for SSL to work (mostly affects you if you are using self signed certificates)
    • The DNS name for your LDAP server must match the name in the LDAP server's certificate for SSL to work
  • Smartcard/CAC authentication requires a PEM encoded list of CAs, proxy or anonymous (if allowed) LDAP credentials, and an SSL enabled webserver

There are more details at the page on how to proceed with this.

Change History (31)

comment:1 Changed 12 years ago by crschmidt

Component: GeneralSAC
Owner: changed from tmitchell to sac@…

comment:2 Changed 12 years ago by martin

All PHP-related packages that were shipped with the distribution on 'osgeo2' have been removed. Such script was used to configure PHP:

./configure --prefix=/usr/local --with-apxs2=/usr/sbin/apxs \
--disable-cgi --with-openssl --with-gettext --with-ldap \
--with-readline --with-pdo-pgsql --with-pgsql \
--with-mysql --with-pdo-mysql --with-mysql-sock=/var/lib/mysql/mysql.sock \
--without-pdo-sqlite --without-sqlite --with-xmlreader --with-xsl \
--with-gd --with-jpeg-dir --with-png-dir --with-zlib-dir --with-bz2 \
--with-ttf --with-freetype-dir \
--enable-sysvshm=yes --enable-sysvsem=yes --enable-memory-limit

Wiki database access parameters can be read from the "LocalSettings?.php" file. We're running MySQL here, so the GRANT for database access looks a bit funny:

mysql> GRANT all on osgeo_wiki to 'wiki'@'localhost';

comment:3 Changed 12 years ago by martin

While we are at it, I'd like to make our Wiki a bit nicer by eliminating the "index.php" string in the URL's. These are the rules that I prefer to apply:


comment:4 Changed 12 years ago by warmerdam


I'm supportive of this idea, as long as the old urls continue to work too, since they are published all over the place.

comment:5 Changed 12 years ago by tmitchell

Sounds good to me too.

comment:6 in reply to:  4 Changed 12 years ago by wolf

Replying to warmerdam:


I'm supportive of this idea, as long as the old urls continue to work too, since they are published all over the place.

That could be done with a

RedirectMatch permanent /index.php(.*)$\1

This will result in all old links resulting in a HTTP response code of 301 (which the browser automatically redirects). Hopefully search engines will take note of this too.

comment:7 in reply to:  3 Changed 12 years ago by martin

Replying to martin:

While we are at it, I'd like to make our Wiki a bit nicer by eliminating the "index.php" string in the URL's.

Changes in /var/www/wiki/LocalSettings.php


$wgArticlePath      = "$wgScript/$1";


$wgArticlePath      = "/wiki/$1";

Changes in /etc/httpd/conf.d/hosts/wiki.conf

Add to each <VirtualHost? [...]>

  RewriteEngine On
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule /wiki/(.*)$ /index.php?title=$1 [PT,L,QSA]
  RedirectMatch permanent ^/index.php/(.*)$ /wiki/$1


comment:8 Changed 12 years ago by tmitchell

  RewriteRule /wiki/(.*)$ /index.php?title=$1 [PT,L,QSA]

Just curious why you rewrote to the "/wiki/" prefix - was there a particular quirk you were avoiding? I'd love to, avoiding "/wiki/" altogether. But I don't understand the technical implications.

comment:9 Changed 12 years ago by wolf

Owner: changed from sac@… to wolf

comment:10 Changed 12 years ago by wolf

Status: newassigned

Work starts June 18th

comment:11 Changed 12 years ago by warmerdam

Cc: warmerdam hobu added

comment:12 Changed 12 years ago by warmerdam

Cc: martin tmitchell added

comment:13 Changed 4 years ago by strk

Keywords: ldap wiki added

comment:14 Changed 4 years ago by strk

Component: Systems AdminWiki

comment:15 Changed 3 years ago by strk

The updated link to LDAP authentication extension for MediaWiki?:

comment:16 Changed 3 years ago by Jeff McKenna

Cc: Jeff McKenna strk Cwillmes added; warmerdam hobu tmitchell removed

comment:17 Changed 3 years ago by astrodog

Owner: changed from wolf to astrodog
Status: assignednew

Taking, the solution we want for the new site should also solve this, so we might as well get both...

comment:18 Changed 3 years ago by astrodog

Status: newassigned

comment:19 Changed 3 years ago by strk

This functionality may help to merge local and LDAP accounts:

Astrodog: any news about your plan to fix this ?

comment:20 Changed 2 years ago by neteler

Cc: sac@… added

IMHO this should become a paid job. This report is open for 10 years...

comment:21 Changed 2 years ago by strk

+1 on paying for this.

How about sending an official motion to the list to make a call for offers to deal with it ?

comment:22 Changed 22 months ago by strk

Cc: jive added

For reference: Board just realized this problem (#2139) Sounds about time to gather offers to do the work... I suggest we contact the authors of Wikimedia LDAP plugin(s) and ask for a quote to do whatever is missing to complete the migration, if nobody else from SAC want to to place a bid.

comment:23 Changed 22 months ago by martin

My own plan for merging Wiki- and LDAP-logins (a couple of years ago) envisioned a custom extension to the Wiki login page as the first step, asking Wiki users to enter their LDAP username after a successful Wiki login.
The second step included a page to ask LDAP users to enter their Wiki username after successful LDAP login.
Or something along these lines, which would allow to match Wiki and LDAP logins against each other without manual intervetion.

This never happened because nobody was available and skilled at the same time to modify the Wiki login page accordingly. Thus, even though this would have allowed almost fool-proof matching, I have to admit it has failed.
The UserMerge? Wiki extension in contrast, while allowing to merge user logins, requires not only manual action in the process of merging user logins but also manual verification of the respective identities.

Adding LDAP and UserMerge? to the Wiki is pretty simple from a *technical* point of view. Therefore the question boils down to: Which method is preferred from an *organizational* point of view ?

comment:24 Changed 22 months ago by jive

Following on to board f2f meeting "volunteer-confusion-over-user-ids" topic which reopened this issue:

The board discussion indicated it would be acceptable to just go to LDAP, with full understanding that a portion of the wiki users would not have access after the transition (until they established an OSGeo userid).

Is there an advantage to mapping LDAP username to Wiki username that I am not seeing?

comment:25 Changed 22 months ago by strk

Advantage of mapping would be, I guess, not leaving thousand of unaccessible accounts, orphaned content and identity split

comment:26 Changed 22 months ago by martin

As far as I can see, there are two issues in "just go to LDAP" - please, whoever knows better, correct me, if I'm wrong:

1.) The vast majority of Wiki edits will refer to an author not available in the LDAP user database after the switch, simply because most of them don't match.

2.) There are more than 5k users in the Wiki user database, more than 20k users in OSGeo LDAP and more than 1k overlapping user names between both, which will lead to conflicting user names in the Wiki after the switch.

While 1.) will just disturb Wiki editors, because they don't "own" their edits any more, 2.) will likely ask for a solution because it'll add confusion in itself.

comment:27 Changed 22 months ago by strk

Would UserMerge? (URL?) allow fixing both points in the long run, beside the envisioned manual effort ? Does it necessarely need to be manual, btw ? Can we help it programmatically with some email based matching ?

comment:28 Changed 22 months ago by martin

As far as I can tell, UserMerge? works by - manually - entering two existing user names, one being just a source and another being the common destination.
Maybe we can add automated matching and scripting to the process but apparently we're short of expertise on automating MediaWiki?, therefore I don't know who's capable of adding the missing bits.

I also have little confidence in the quality of EMail addresses in the Wiki database, because a long-term policy had been "we don't want any obstacles in the process of registering with OSGeo". Therefore I would expect a lot of garbage and false EMail addresses on the Wiki as well as in LDAP.
That's why I proposed to ask authenticated LDAP users to provide their Wiki account name and vice versa in order to ensure, the matches are valid (at least most of them).

Moreover, I have no idea what's going to happen when we use UserMerge? for merging Wiki user "joe" into LDAP user "karl" while "joe" is a valid user name in LDAP as well. This probably means we need to resolve conflicting user names beforehand (see above).

Disclaimer: Especially now, after realizing I was unable to carry out my own plan, I do *not* intend to hold OSGeo back from switching the Wiki over to LDAP authentication. I just want to add my thoughts to this discussion, hoping they'll help in making an educated decision.
Maybe someone will even prove me to be totally wrong.

comment:29 Changed 22 months ago by martin

Please also read the mailing list thread starting about here:

comment:30 Changed 22 months ago by TemptorSent

Regarding handling merge of existing wiki users and osgeo account users:

  • Existing users with accounts on the wiki should be the only ones inconvenienced in the migration.
  • No loss of authorship information should occur.
  • No namespace conflicts should occur between old wiki accounts and new LDAP accounts.
  • All future logins should go through the OSGeo LDAP authentication service.
  • Users should provide their wiki account credentials to migrate their existing wiki account after authenticating to their OSGeo LDAP account.
  • Non-migrated usernames in database may be modified to prevent collision with newly migrated users if necessary.

comment:31 Changed 22 months ago by TemptorSent

Proposed migration plans following #OSGeo-sac meeting 2018-03-29

Martin noted that the current MediaWiki? instance is somewhat out of date, therefore I propose the following migration to both a newer mediawiki version and ldap authenticated accounts:

  1. Setup clean new MediaWiki? instance, including all necessary extensions.
  2. Export database from current instance and import to new instance.
  3. Rename all existing user accounts with prefix, such as "_wikiuser_".
  4. Disable login to any account having the prefix.
  5. Force all logins through OSGeo LDAP authentication.
  6. On first login of a LDAP user to the wiki, prompt user to provide credentials for any existing wiki accounts they wish to merge; prepend prefix to authenticate and merge if valid.

We will want to do this on a testing basis first to work out any issues, then freeze the existing instance before importing clean with a fresh dump and swapping in the new instance.

Note: See TracTickets for help on using tickets.