If your client has more than one person maintaining the site, you should consider providing role-based ACL. What is "role-based" ACL and why should you use it instead of the 1.5 approach of ACL?

To be candid, Joomla 1.5 had one glaring problem that prevented it from being suitable for many corporate projects. The site developer was extremely limited in providing varied roles for staff to maintain the website.

ACL in 1.5

2.5 installs with a set of groups
that resemble those in 1.5

Responsibilities for different sections of the site could not be isolated from each other. If a user needed one feature or a particular component that required the user to be an "administrator," we had to make that user an admin. Almost invariably, we would give more rights and access to more areas than what any given user needed. This limitation is unacceptable to most companies.

Fortunately, that limitation has been removed in 2.5. The problem is… many site developers don’t stray very far from the 1.5 model of ACL.

What does role-based look like?

A role tends to represent some logical task or set of responsibilities that belong within an organization or company. It is assignable to an individual and can be transferred to or shared by other individuals. A "role" is a concept that an organization defines and routinely understands.

For example, the role of "order fulfillment" will grant a user the ability to access orders, access shipping information, change an order’s status, and adjust inventory count for the products being sold. But another role might be required for managing of product information, and another for accessing a customer’s financial information or offering refunds. One user might be assigned to all of these roles, while another user is assigned to just one of them. The full capabilities of a user are determined by the aggregation of roles that are assigned to him or her.

Typical qualities of a role

The access and permissions associated with a role are just enough for performing a task or set of related tasks. This enables the principle of "least privilege."

The tasks and responsibilities of one role are isolated from (and typically non-overlapping with) those of the other roles. This enables the principle of "separation of duties."

• A role represents the combination of areas that can be access with levels of permissions.
• A person can be assigned to more than one role.
• More than one person may share the same role.
• A role can be easily added, removed, or transferred among users.
• A role corresponds in name and capabilities to the business concept of that “role.”

Most of these could not be implemented in Joomla 1.5. All of them can be in 2.5. The ACL model of 2.5 enables us to implement all of these qualities, but it does not require nor enforce us to do so. In fact, the default ACL configuration looks like and emulates the ACL of 1.5.

A role-based ACL looks significantly different from the ACL we get out-of-the box.

Sander Potjer, developer of ACL Manager, told me that he prefers to remove most of the default user groups and reconstruct the user groups as needed for a given project. For a role-based solution, this makes sense. Until recently, this might not have been practical. Far too many extension developers failed to provide basic ACL support for their 1.6/1.7/2.5 components. As a result, we could not use a custom group for accessing these components – we had to assign a user to "manager" or even to "administrator"! Fortunately, the current versions of ACL Manager can automatically provide basic ACL to 2.5 components that lack it. Finally, we can ignore and even remove "manager" and "administrator." If you implement a 100% role-based approach, arguably you no longer need them.

What does role-based buy us?

The role-based model corresponds very closely to an organization’s business rules. Business leaders understand the concept of roles, and a study of several organizations reveals that they prefer to define and manage access control in terms of the various roles assigned to individuals. If we model our ACL according to their business rules, we will be handing to our clients a CMS that accommodates their staffing needs and future changes.

Consider the realities that businesses face: throughout time, staff and staff responsibilities change. People come and go, and responsibilities get shifted. Roles might need to be assigned, removed, or changed quickly. Sometimes multiple people share a role. Often a staff member will retain multiple roles. Roles should be assignable per individual, and at times a role might be assigned or removed as an exception to a job title or to a class of users. Smart security calls for people to have access only to what they need.

Businesses expect to be able to do all this. If we customize the ACL to be organized around role-based groups, then we deliver to our clients a system for managing users and user roles that is intuitive and quick to administer.

This screen shot illustrates three benefits of a role-based ACL. First, assignment of roles to users is intuitive. It uses terminology that is understandable by business. Access control is segmented by how the organization understands and defines roles. The important role of managing users and assigning user rights should belong to the most appropriate person – even if that person lacks a technical understanding of the system. This role-based system is adequately intuitive.

Second, roles are freely aggregated and can be aggregated uniquely per user. This reflects the realities of staffing and of volunteer pools.

Third, each user of the CMS will have access only to those parts needed for the tasks belonging to that role. If we set up role-based access levels that correspond to role-based groups, we can accomplish what you see here: each user sees a backend tailored to the set of roles assigned to him or her.

A different way of thinking about ACL

This article introduces a different way of thinking about access control. It is not a new model. "Role-Based Access Control" (RBAC) was formally described in 1996, and it is commonly used by businesses and information systems. In fact, the new structure of Joomla’s ACL corresponds to the model known as RBAC₁ – it does if we employ Joomla’s "user groups" to represent "roles" instead of "users types" (a subtle-but-important distinction). So Joomla! does provide the foundation for building a serious system of role-base access control.

This article makes a case for shifting to a role-based approach. A follow-up article will discuss implementation and illustrate a working approach.

It might seem safer not to stray far from the 1.5 model. But organizations that have multiple people managing their websites expect something better. We can deliver better. And when we bring Joomla! to corporations and larger organizations, we need to deliver better.