By Jen Kramer on Saturday, 31 December 2011
Category: January

Joomla 1.6, 1.7, and 2.5: ACL Concepts Overview

One of the most powerful new features in Joomla 1.6 and later versions is Access Control Lists (ACL). ACL stands for access control lists. It refers to who has permission to do what on the website, including read, create, edit, delete, or log in, among other permissions.

Thank you to Katerina Vorobyova for translating this article to Russian!

Thank you to Lo Jen-Chih for translating this article to Traditional Chinese!

Thank you to Helvecio for translating this article to Brazilian Portuguese!

This article is based on two articles originally written for Joomla 1.6. This article was written in December 2011, prior to the release of Joomla 2.5. However, it assumed that ACL concepts will not change between Joomla versions, even if minor changes to the interface do occur.

One of the most powerful new features in Joomla 1.6 and later versions is Access Control Lists (ACL).

ACL stands for access control lists. It refers to who has permission to do what on the website, including read, create, edit, delete, or log in, among other permissions.

Many think of ACL as relating to the front end of a website only. For example, when I log into the website, what articles do I have available to me? And if someone else logs into the site, do they see the same articles, or do they see different ones?

However, ACL also relates to who has rights to create, edit, and delete content; who can publish and unpublish content; who can log into the front end or back end of the website; and who can make changes to which components, modules, and templates.

Just because you can doesn't mean you should! ACL is complex, and it takes some time to understand exactly how it works. For many sites, perhaps even most sites, you might not need anything beyond the default Joomla configuration. However, if you're building a larger site, it could come in handy.

Examples of where ACL would be required include:

ACL can also be used to build a simplified administrator interface, eliminating areas where a client would not need to visit to make changes to the site. In Joomla 1.5, you could make a client a manager, but they would be able to edit any component, any content on the site, and make changes to menus. With Joomla 1.6 and higher, you can refine ACL so a client can access only specific categories of articles (or specific articles), specific components (or none at all), and so forth. Via ACL, you can improve backend administrator usability for your client.

ACL in Joomla 1.5

Joomla 1.5 has a limited and fixed ACL system. If you’ve worked with Joomla 1.5, you’ve seen how you can set a menu item or article to be viewable by the public, registered users, or “special” (authors and above). Likewise, you probably know that registered users can’t log into the back end of a Joomla site, but a super administrator can. Joomla 1.5 ACL is hierarchical, meaning that each user group inherits permissions from the groups below it.

A full explanation of Joomla 1.5’s groups can be found at brian.teeman.net. Groups include public, registered, author, editor, publisher, manager, administrator, and super administrator.

Joomla 1.5's access levels include public, registered, and special. Public indicates that anyone can see the content. Registered indicates that those with registered user access and higher can see the content. Special is for Author groups and higher only. There is no way to add additional access levels, nor is there any way to segment audiences more finely.

ACL in Joomla 1.6 and higher: Overview

Joomla 1.6+ ACL is not necessarily hierarchical. You can set up groups with whatever permissions you wish. These permissions are inherited from parents in the case of groups, but they are not inherited in the case of access levels. At a minimum, all user groups are children of the Public group.

There are four aspects to the ACL system in Joomla 1.6+. These include the user, the group, core permissions, and access levels. I've represented these in the following diagram to describe their relationship, and I'll go through each in detail.

User

This is the easiest one to understand — that's you, or someone else visiting the website. A user does not have to have an account to be considered a user of the website. That user would still be considered a public user. Individual users may be assigned to one or several groups. You cannot assign core permissions directly to users; these are assigned to the group.

Core Permissions

Core permissions are assigned to the group, not to individual users. (If you want specific core permissions for a single user, you would need to create a group for that single user.)

Core permissions include:

The core permissions are set in the Global Configuration, under Site - Global Configuration, then clicking on the Permissions tab.

Understanding Core Permissions in Global Configuration

In the Manager group shown above, and in all other groups except for Public, each one of the dropdowns shown here has three options: Allow, Deny, and Inherited. The Public group is the parent for all groups underneath. The Public group's dropdowns has three values, which include Allow, Deny, and Not Set.

A full explanation of each user group's permissions is explained below.

Special Note about Core Permissions Assigned in Global Configuration

When core permissions are set at the Global Configuration level, they carry through the entire site and through all areas of the site. For example, an Author has the Create permission assigned globally. That author may create an article in any category on the website. The Create permission also means they could create a new weblink from the front end of the website, if the weblink component is in use. You may want to think carefully about where permissions are assigned within Joomla. You do not have to set the Create permission in Global Configuration if you want a user group to be able to create articles and categories. You could also assign this permission within the Options in the Article Manager. I will go more in depth about where to assign permissions in later articles.

All About Deny

You might be tempted to set all of these dropdowns to specifically say Allow or Deny so it's easier to read.

However, I would strongly encourage you NOT to do that.

If Deny is set in the permissions, even if you set an Allow for a higher level user group, the lower level Deny would be inherited and would override the Allow.

For example, if you set the Public group dropdowns to Deny for all, there's no point in having any higher level groups! Everyone would be denied from doing anything on the website forever with the exception of the Super Users.

User Group

A user group (also called groups) is a group of users who share the same permissions. Using the Joomla 1.5 groups as an example, the publisher group has the right to log into the front of the website, create new articles, edit any articles on the site, and publish or unpublish articles. Anyone in the publisher group has the same permissions to do these same things.

Unlike Joomla 1.5, however, a user may be assigned to multiple groups. A user may be in the publisher group as well as the administrator group, for example.

You can create your own groups and assign them their own set of core permissions. Core permissions are inherited between groups.

A group might be created for two different reasons. One would be to view content on the front end of the website. (User groups are assigned to access levels to see content on the front end of the website.) The other would be to specify what content can be created, edited, deleted, published or unpublished, or managed by that group.

By visiting the website, a site visitor is considered a user belonging to the public group.

The public group may not be deleted, but all other groups may be deleted. (However, I'd recommend you keep them, because they give you a good model of how permissions inheritance works.)

The Default Groups

By default, Joomla 1.6 and higher comes configured with the same groups as appear in Joomla 1.5. The groups and their core permissions are as follows (consider singing along to "The 12 Days of Christmas" while reading):

The default groups and their permissions are represented in the Global Configuration (under Site - Global Configuration - Permissions).

Access Level

Access levels refer to who can see what content on the front end of the website. Essentially, this amounts to read permissions on the front end of the website.

Historically, there have been three access levels: public (which anyone can see), registered (you must be logged in to see the content), or special (you must be a logged in author or higher level group to see the content).

These access levels are still present in 1.6+ as default settings, but you can also create your own access levels.

Access levels do not inherit their permissions. If an article is set to be viewable by publishers only via a custom access level, even super administrators cannot view that article. You must assign super users to also be part of the publisher group in order to view this article on the front end of the website, or you must assign super users and publishers to the same access level to see the content.. (In all cases, as a super user, you are able to edit this article on the back end.)

What's next?

I will be writing a series of case studies that you can follow for putting the above principles into action. The examples will include:

Leave Comments