Enterprise use of MediaWiki

This is a page for coordinating various community efforts for using MediaWiki in a corporate/enterprise/organizational setting.

Enterprise MediaWiki Resources
As of this writing, we're still in the formative stages of trying to build an enterprise MediaWiki community, following up from an Enterprise MediaWiki BOF at Wikimania 2006. It's not clear that it entirely makes sense to have a community defined that is independent of the general MediaWiki community, but it's good to have that discussion.

Mailing List
A mailing list was created in August, 2006 to discuss enterprise issues. It's currently a low traffic list, so feel free to join and introduce yourself:

http://mail.wikimedia.org/mailman/listinfo/mediawiki-enterprise

IRC
There's not a dedicated IRC channel to enterprise issues, but the best thing to do if you'd like to discuss this is to pop onto the #mediawiki IRC channel to discuss. Make sure that robla is paying attention if he's logged on (for example, by typing "/msg robla there's enterprise stuff on #mediawiki")

Other channels
See the MediaWiki Communication page for more options.

Issues for MediaWiki in the enterprise
Below are issues for users of MediaWiki in an enterprise setting. Some issues below aren't typically a problem for public Internet deployments of MediaWiki, while others are, but may not be as acute as they are for enterprise users.

Authentication
Most public Internet deployments of MediaWiki use the standard authentication database as configured in MediaWiki. However, enterprise deployments typically need to tie into the corporate login structure. Here's some resources that help you deal with that:


 * Ryan Lane's LDAP Authentication plugin - since LDAP systems are so common in enterprise systems.
 * AuthPlugin interface - generic interface for creating new authentication plugins.

Limiting read access
not much has changed. I'm planning to possibly discuss ways in which User.php could be overridden, extended, and/or stabilized as an extension interface. The idea would be a system where group memberships are stored in an external database, as well as capability assignments (e.g. LDAP group "admins" gets the "edit" capability on resource "MediaWiki: namespace")  This is admittedly pretty fuzzy right now.
 * Authorization plugins - not much as of MediaWiki 1.5....I'm guessing

=Read-restricted access=

The core developers of MediaWiki don't have an interest in limiting read access to portions of a MediaWiki install. Since MediaWiki wasn't designed to be used in this way, it's very difficult to prevent accidental entry points to material for a determined user.

Here are just a few examples of ways of accessing content:
 * Page transclusion
 * Export hooks
 * Page history
 * Searching

If page names are meant to be confidential (e.g. "super secret contract between Foo Corp. and Bar Corp."), that just makes matters worse.

One suggestion from the Wikimania BOF:
 * You might set up a hot mirror. Point authors at the master wiki with htaccess protection, point users at a read-only mirrors.  Once you set it up, maintenance is trivial.  This tells how to mirror the OpenZaurus wiki: http://wiki.openzaurus.org/Admin/MirrorHowto .  You may be able to adapt these instructions to set up your own master and any number of read-only mirrors.  My mirrors update nightly; updates up to every 10 minutes should be feasible depending on the number and size of your pages.  Contact me if you have any questions: bronson@rinspin.com

One subject for discussion on the mediawiki-enterprise mailing list is what interfaces could be added to the code such that an ACL-maniac extension to MediaWiki could exist, without a big support burden on the core team. 

External Authorization plugins

 * What this means: being able to manage group memberships in external database rather than in internal database
 * Not really being done (?)
 * How to do it: override User.php?
 * Other hooks?
 * OpenID is in MediaWiki svn. It's live at http://wikitravel.org/review/Special:OpenIDLogin
 * Page by Page Access Control using Access Control Extension for MediaWiki
 * PageSecurity extension.

New distribution mechanisms

 * Debian package for MediaWiki
 * RPM (?)
 * Does a PEAR distribution make sense?
 * Does it make sense to package MediaWiki extensions as .deb/.rpm/PEAR thingies?
 * I mentioned automating maintaining multiple instances using svk during the talk. It works well.  I will try to write an article about it in the next few days; check http://u32.net or bug me: bronson@rinspin.com

MediaWiki, I'm assuming there's an RPM out there. Does a PEAR distribution make sense? Does it make sense to package MediaWiki extensions as .deb/.rpm/PEAR thingies?
 * New distribution mechanisms. There's already a Debian package for

=Structured data in enterprise use=


 * Wikidata
 * Semantic MediaWiki
 * Wikicalc http://softwaregarden.com/wkcalpha/


 * Structured data - I know that in my last job, there were several things we used a wiki in lieu of a database for (e.g. we kept a list of new licensees of our technology on a wiki). It was nice, because we had the flexibility to add fields willy-nilly.  So, it may be interesting to discuss the enterprise applicability of projects like

=WYSIWYG Editing=


 * Issue discussed extensively at Hacking Days
 * Several non-MediaWiki markup solutions (FCKeditor very popular here)
 * Challenge for mainstream solution: lack of formal Wiki-syntax definition


 * Check MediaWiki+FCKeditor for more info on this. FredCK 14:34, 28 July 2007 (UTC)

=Other stuff=


 * Marking stable/approved versions of articles
 * Training
 * Possibility to replicate to a local system. This is needed to Consultants with no access from the customersite to the Company Wiki.