Difference between revisions of "IntraACL"

Revision as of 14:46, 18 November 2013

IntraACL is a MediaWiki extension.

• Main purpose: Best page-specific rights extension for MediaWiki. It is based on HaloACL, correcting its endless bugs and inconveniences.
• Repository: https://github.com/mediawiki4intranet/IntraACL
• Homepage: http://wiki.4intra.net/IntraACL 
• Compatible MediaWiki versions: guaranteed 1.19-1.25, maybe others 
• Authors: Vitaliy Filippov & Stas Fomin. Based on HaloACL by ontoprise GmbH, 2009.
• License: GPLv3.0+ 
• Created: 2010-09-03 
• Last version: 2.1.8 
• Our rating: Definitely useful (5)

Status for Mediawiki4Intranet distribution:

• Inclusion date: 2010-09-03
• Included version: newest available
• Improvement status: Created by MediaWiki4Intranet project

Introduction

Page-specific rights in MediaWiki

MediaWiki is not designed to be a CMS, or to protect sensitive data. To the contrary, it was designed to be as open as possible. Thus it does not inherently support full featured, air-tight protection of private content. But with the massive increase of MediaWiki use in corporate intranets and the many CMS-like features emerging, demand for tighter security is emerging.

As you know, MediaWiki was designed as Wikipedia engine. Wikipedia is open and doesn’t need access rights. Moreover, one of WikiWiki principles is to allow easy and fast editing for anyone, and of course, read access must also be open.

This is why MediaWiki is not designed to protect anything from anyone, except from anonymous editing. There is plenty of ways to break the read rights (page inclusion, recent changes and etc), especially when any of 1700+ MediaWiki extensions can use direct database access (if it couldn’t, MediaWiki would probably be as fast as all other «global and stable Ntrprise»).

Examples of such ways are described here: Security issues with authorization extensions and here: page with comparison of existing access control extensions, from which we did know about HaloACL.

Original HaloACL already solves most of these problems, but when we tried to use it, we discovered many bugs, inconveniences, and slow interfaces (thanks YAHOO UI library ). So we started to improve it, and then forked it and called IntraACL.

IntraACL features

• Interactive right editor (special page).
• Ability to create pages protected from beginning.
• Page protection.
• Category protection.
• Namespace protection.
• Right inclusions.
• Right definition using Wiki pages inside a special namespace.
• User groups, group-into-group inclusions — orthogonal to MediaWiki groups, also stored on wiki pages.
• Easy protection of content used on a page.

Requirements

In theory IntraACL should work for any MediaWiki >= 1.14. But in fact, patches are available for at least 1.18.

Installation

First checkout IntraACL code to extensions/IntraACL.

There is a new version available in 'storage-rewrite' git branch which should deliver better performance, but it is in beta state by now. It passes right evaluation tests and it should have no critical bugs, so you can already use it.

Then add the following lines into your LocalSettings.php:

require_once('extensions/IntraACL/includes/HACL_Initialize.php');
enableIntraACL();

You can also add custom configuration options before enableIntraACL() call. For the option list, see extensions/IntraACL/includes/HACL_Initialize.php or this page.

Then apply patch for appropriate version of MediaWiki:

cd YOUR_WIKI_INSTALLATION_DIR
patch -p0 < extensions/IntraACL/patches/IntraACL-MediaWiki-<YOUR_VERSION>.diff

Run MediaWiki database update tool:

php maintenance/update.php

Check your extensions

You should check all your extensions for compatibility with IntraACL because of possible security breaches.

Configuration

# Set this variable to false to disable the patch that checks all titles
# for accessibility. Unfortunately, the Title-object does not check if an article
# can be accessed. A patch adds this functionality and checks every title that is
# created. If a title can not be accessed, a replacement title called "Permission
# denied" is returned. This is the best and securest way of protecting an article,
# however, it slows down things a bit.
$haclgEnableTitleCheck = false;
 
# This variable controls the behaviour of unreadable articles included into other
# articles. When it is a non-empty string, it is treated as the name of a message
# inside MediaWiki: namespace (i.e. localisation message). When it is set to an
# empty string, nothing is displayed in place of protected inclusion. When it is
# set to boolean FALSE, inclusion directive is shown instead of article content.
$haclgInclusionDeniedMessage = 'haloacl-inclusion-denied';
 
# This flag applies to articles that have or inherit no security descriptor.
#
# true
#    If this value is <true>, all articles that have no security descriptor are
#    fully accessible for IntraACL. Other extensions or $wgGroupPermissions can
#    still prohibit access.
#    Remember that security descriptor are also inherited via categories or
#    namespaces.
# false
#    If it is <false>, no access is granted at all. Only the latest author of an
#    article can create a security descriptor.
$haclgOpenWikiAccess = true;
 
# Values of this array are treated as language-dependent names of namespaces which
# can not be protected by IntraACL.
$haclgUnprotectableNamespaces = array();
 
# If this is true, "ACL" tab will be hidden for unprotected pages.
$haclgDisableACLTab = false;
 
# If $haclgEvaluatorLog is <true>, you can specify the URL-parameter "hacllog=true".
# In this case IntraACL echos the reason why actions are permitted or prohibited.
$haclgEvaluatorLog = true;
 
# If you already have custom namespaces on your site, insert
#    $haclgNamespaceIndex = ???;
# into your LocalSettings.php *before* including this file. The number ??? must
# be the smallest even namespace number that is not in use yet. However, it
# must not be smaller than 100.
$haclgNamespaceIndex = 102;
 
# This specifies how different right definitions which apply to one page combine.
# There may be page, category and namespace rights.
# Possible values:
# - HACL_COMBINE_EXTEND: user has the right if it is granted within ANY of the applicable definitions.
# - HACL_COMBINE_SHRINK: user has the right only if it is granted within ALL applicable definitions.
# - HACL_COMBINE_OVERRIDE: more specific rights override less specific ones.
#   I.e. page rights override category rights, which override namespace rights.
$haclgCombineMode = HACL_COMBINE_EXTEND;
 
# Names of MediaWiki groups members of which are IntraACL super-users
# and can view and edit all articles, ACLs and etc. It is needed to
# have someone who can repair incorrect right definitions created by users
# (which is a very common scenario in the case of IntraACL because of a
# relatively complex right model).
$haclgSuperGroups = array('bureaucrat', 'sysop');
 
# Preload 1000 SDs individually granted for current user during right checks.
# If your database is very large and this number is exceeded, IntraACL will begin to
# make individual DB queries for the access check of each separate page.
$iaclPreloadLimit = 1000;

MediaWiki 4 Intranet

You can just use Mediawiki4Intranet bundle. It already includes IntraACL and many other useful extensions which are made compatible with it.

See Mediawiki4Intranet.

The method of IntraACL installation via the super-duper-installer of Halo MediaWiki bundle is now removed as very non-standard.

Patches

Patches are available for 1.18.6, 1.19.8, 1.20.7, and 1.21.2 in the repository under /patches.

Usage

Right definitions and group definitions (IntraACL has its own group system, just like HaloACL) are stored on wiki pages in a special 'ACL' namespace.

Quick start

First install and configure IntraACL.

Protect a page

• Open a wiki page. You’ll see «ACL» tab between «Article» and «Talk» tabs.
• Click «create with editor». You’ll see the IntraACL right editor.
• Click the editbox which is located next to dropdown with «User» item selected, and start typing the name of some user. IntraACL will suggest you the matching users.
• Select some user by clicking his name.
• Click «Full Access».
• You can add other users just like that.
• Click «Save» button.

Congratulations, that’s your first protected page! Only selected users will be allowed to do any action with it.

Note that you can return back from ACL article to the protected article itself by clicking «Page» tab.

Protect a category

Similarly, you can protect a category — it will get protection along with all its content including pages and subcategories:

• Go to the category page.
• Click «ACL», click «Create with editor».
• Select users and rights that you need, click «Save».

Rights are «cumulative» in IntraACL by default — that is, if you’ll protect a page individually and then protect a category in which it’s included — all users mentioned in either of these right definitions will get access rights. This is also correct for namespaces and can be changed via a configuration option ($haclgCombineMode).

Protect a namespace

Namespace protection is also similar, one difference is that you’ll need to open IntraACL editor from the special page:

• Click «Special pages» in the left toolbar, select «IntraACL» from the long list of special pages and click it.
• Click «Create new ACL definition».
• Select «Protect namespace:» the «Definition target» drop-down list.
• Click the editbox located nearly — you’ll see the list of namespaces. Select one of them.
• Then do the same actions you did with page/category protection.

View and delete ACLs

• Click «Special pages», select «IntraACL».
• You’ll see the full list of right definitions. You can go to the editor by clicking any of them.
• To delete some definition, click «Delete» in the editor, and then confirm deletion. Deleted definitions obviously don’t apply to page anymore.