IntraACL

What links here (14) →

Subpages (1) →

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 are 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

• MediaWiki >= 1.18
• PHP >= 5.3
• MySQL/MariaDB >= 5.1

Installation

First checkout IntraACL code to extensions/IntraACL:

git clone https://github.com/mediawiki4intranet/IntraACL

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 #Configuration.

Then apply patch for appropriate version of MediaWiki:

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

Run MediaWiki database update tool:

php maintenance/update.php

Extension interface

ANY MediaWiki extension installed together with IntraACL MAY lead to SECURITY BREACHES. This is because of MediaWiki by-design openness and extensibility and the need for direct database queries from extension code. You should check that all your extensions perform read permission checks using the interfaces specified below; another way is to use MediaWiki4Intranet bundle - extensions included in it are already patched to be compatible with IntraACL (except SemanticMediaWiki - patches for it are now in a separate branch).

The interface is very simple - extensions should just check permissions using $title->userCanRead() (for MediaWiki 1.18 and below) or $title->userCan('read') (for MediaWiki 1.19 and above) before displaying any content related to an article specified by the Title object $title.

Starting with 2.1.0, IntraACL also supports page filtering inside DBMS, using a stored procedure. This is useful to speed up selection of big page sets, and to correctly paginate article lists in the UI. See FilterPageQuery hook method in includes/Evaluator.php for details.

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, 1.21.2 and 1.22.0 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.

IntraACL objects

Right definition

Right definition defines some rights and is stored on a wiki page in «ACL» namespace. «Some» means one of:

• Namespace ACL — ACL:Namespace/EnglishNamespaceName (or ACL:Namespace/Main for main namespace which has no name).
• Category ACL — ACL:Category/CategoryName.
• Page ACL — ACL:Page/EnglishNamespaceName:CanonicalPageName. EnglishNamespaceName: is omitted for pages from the main namespace.
• Right template — ACL:Right/TemplateName. doesn’t protect anything, but can be included in other pages. «Inclusion» doesn’t mean standard MediaWiki template transclusion ({{Template}}), but is an IntraACL method, but in fact, it’s very similar: all rights from an included ACL just get into the target ACLs as if they were defined inside it.

You don’t have to remember all these rules and right syntax. There is an interactive editor accessible from each ACL and group page that allows you to edit right and group definitions more easily.

Each page can have multiple ACL applied to it: page ACL, namespace ACL and several category ACLs. There are 3 modes of combining these ACLs switched via $haclgCombineMode configuration variable:

«Extend» mode (default)

The resulting access mode is the union of all applicable ACLs. That is, a user gets some right if it is granted to him in either of applicable ACLs.

«Shrink» mode

The resulting access mode is the intersection of all applicable ACLs. That is, a user gets some right if it is granted to him in all applicable ACLs.

«Override» mode

«More specific rights override less specific ones». That is, category ACLs override namespace ACLs, while page ACLs override category and namespace ACLs. At the same time, if a page is included in several protected categories, their rights are always united, because no category is considered «more specific» than other one.

If no applicable ACLs if found for a page, then IntraACL decides whether to grant access to it using $haclgOpenWikiAccess configuration variable. If it is true, then any action can be done by with such pages by anyone. If it is false — any action is denied by default, except for the members of $haclgSuperGroups which is bureaucrat and sysop by default, so the wiki administrator can still grant access right.

An ACL (a right definition) can consist of:

Inline rights

Inline right is a «base permission unit» and grants a set of actions to a set of users. See below.

ACL manage rights

These rules allow a set of users to edit the ACL itself.
The syntax for them is {{#manage rights: assigned to = User:UserName, Group/GroupName}}.

Inclusions of other ACLs

As already said above, all rights from an included ACL just get into the target ACLs as if they were defined inside it.
{{#predefined right: ACL:Page/Страница | ACL:Right/Default}}

This is very similar to HaloACL, except that these «right definitions» are called either «security descriptors» or «predefined rights» there (the first applies to some page/category/namespace, while the second is a right template).

Inline right

Inline right is a «base permission unit» and just grants a set of actions to a set of users. Its syntax is:

• {{#access: assigned to = User:UserName, Group/GroupName | actions = *, read, write, create, delete, move, manage}}
• assigned to = *: means «All users»
• assigned to = #: means «Registered users»

As you can see, there are two parameters: assigned to defines applicable users, actions defines granted actions. actions can include:

read, edit, delete, move

The names are straightforward.

create

Page creation. Only makes sense in a namespace ACL or inside a category.

*

Full access, equivalent to «read+edit+delete+move+create».

manage

While being similar to ACL’s «manage rights», this action depends on the usage context. While being used in a category/namespace ACL or inside an ACL template, it DOES NOT grant any actions on that category/namespace or ACL template. But if it is included by page ACL, or if the page belongs to a category/namespace which has «manage» action in its ACL, all users being granted «manage» are allowed to edit ACL of that page.
Slightly messy feature, but allows you to allow some users to change the protection of some set of pages while NOT allowing them to change the «parent ACL».

Groups

IntraACL, just like HaloACL, has its own group system, independent from MediaWiki’s standard one. Group definitions are also stored on wiki pages in ACL namespace and are named ACL:Group/GroupName.

A group can include some users and/or other groups, plus the set of users and/or groups that are allowed to modify it.

The syntax of user/group inclusion is:

{{#member: members = User:UserName, Group/GroupName }}

The syntax of group manage rights is:

{{#manage group: assigned to = User:UserName, Group/GroupName }}