Role-Based ACLto improve content management

Randy Carey

iCueProject.com

This is the revised 2014 version of my presentation Role-Based ACL.

Many of the slides here have been slightly changed to accommodate annotations. This helps to convey meaning beyond the pictures.

My current work is with the iCueProject.com. Here we see the problem of the CMS is that it provides only one interface to be used by two different types of users…

A better approach is to provide a separate CMS interface to each of the two user types.

Actually, we can do better yet to provide personalized user experiencesfor each user group. The starting point of doing this is with the ACL –and setting up the ACL with roles.

I’ll start by explaining the ‘mechanics’ of Joomla’s ACL.

Then I’ll explain how permissions are calculated.

Then we can move on to Role-Based. What is it? How is it set up?

I’ll show how roles allow to create a personalized user experience

Then I’ll show how to set it up in Joomla.

Then I’ll reference a few tools that make this process easier

ACL Mechanics

Groups are the foundation of Joomla’s ACL.They know only their name and which other group is its parent.They don’t know about any other parts of the ACL or of Joomla. Simple. Yet this allow us to create a rich expression of rolesthrough custom hierarchies.

Users are connected to the ACL by assigning them to groups.This is the only direct connection they have with the ACL.

Each user can be associated to any number of groups and in any combination.

Next we look at what I call “resources.” These are the other parts of Joomla that connect to the ACL. Technically, these are not part of the ACL – they connect to the ACL system only by referencing it.

Currently, permissions are provided only by the site configuration,by components (and their categories/items), and by modules. Menu items and plugins do not implement permissions.

Permissions are part of the ACL, but it is the responsibility of the resource to provide a list of “actions” for which the ACL can assign permissions.Unfortunately, in some cases, developers don’t do this.

Another thing to note…

For each resource, the permissions screen automatically presentsus with the set of user groups currently held by the ACL. And within each of these user groups is the set of actions that the resource declares.

So permissions are always within the context of the resource first, then within each of the groups, and finally (within each group) assigned per action.

In contrast to permissions, all resources reference access levels.Also in contrast to permissions, each resource references one-and-only-one access level.

Each access level simply defines some set of groups.If any person belongs to any of the groups selected by that access level item,Then that person is included by this access item. So for any resource, the ACL evaluates if the current user is included by thatResource’s access level. If so, then the user has access to the resource. If not, then the user does not have access.

Note: a better term for this item is access list – as its role is to provide a formula that determines which users that are included (having access).

These do not confer “level,” and that term is an unfortunate carry-over from the ACL in 1.5.

One more look at the ACL diagram.

ACL

permissions personalization

When we think of ACL we probably think “permissions.” but “permissions is Just one side of the coin. The other side is “personalization.”

Next we’ll discuss permissions. But later we will talk about personalization.

Permissions (& actions)

Permissions (& actions)

Permissions are managed by the ACL, but for logical reasons, the component is responsible for three things. Let’s look at those…

Permissions (& actions)

1

For permissions to apply to a component, that component must declare a list of actions relevant for it and its data.Below you see the traditional/core actions (create, delete, edit, etc.)

Permissions (& actions)

1

But many developers can do better by offering actions specific to thecomponent’s type and data.

Shown to the left here are the rich setof actions provided by EasyBlog.

Permissions (& actions)

1

2The component is responsible for offering ACL at the desired level of granularity:

component, category, and item.

The ACL cannot force a component to implement permissions – even at the component level. Frustratingly, some developers don’t offer any permissions on their extension!

Permissions (& actions)rc

1

2

3

enforce result

It is the component’s responsibility to enforce permissions and to enforce them correctly.

The ACL can only respond as to whether or not the current user has permission, but the ACL itself cannot enforce the permission.

calculatingpermission

Now we look at how the ACL calculates a permission.

1. for a particular action

1. for a particular action2. Each of the user’s groups

The ACL considers each group to which the user belongs.

Keep in mind that if a user belongs to a group with a parent, then the ACL assumes the user belongs to each parent group tracing back to Public. In this example, belonging to B1 also includes user group B.

The formula is simple.

FIRST: Consider the permission settings for each group to which the user belongs – without considering where that group falls within the group hierarchy.

THEN: Evaluate the set of permission settings (in any order)• If all the permissions are set to Inherit, the result is deny.• If at least one permission is Allow but none are Deny, the result is allow.• If any one of the permissions is Deny, the result is deny – regardless of any other Allows that might be present. A single Deny anywhere results in deny.

1. for a particular action2. Each of the user’s groups3. For extension, category, & object

The same applies to when we need to include the permissions on categories and objects.

Just look at the permission settings of each of the user’s groups at each level: component, category, and object.

1. for a particular action2. Each of the user’s groups3. For extension, category, & object

Rely on the same formula:

• All Inherits is deny.• One or more Allow is allow• A single Deny cancels all Allows and results in deny

So let’s look a permission calculcations from a different data model…

If the component level is set to Allow and nothing is set on the category or object…

All items are allowed. All new items are allowed. All new items in a new category will be allowed.

If the component level is not set…

All items allowed – even new items within this category.

No items are allowed – new items will not be allowed.

Selected items are allowed – other are not allowed and new items will not be allowed

All items denied – even new items within this category.

The Denied items are denied, but All other items and those that are created later will be allowed

All items denyed – even new items within this category.Even an Allow on the item will notundo the Deny on the category.

When the component is allowed by a Deny is set inside it…

ACL Manager is a great tool for helping you see the results of your ACL settings.

RBAC1

Let’s look at how Role-based ACL looks

RBAC1

Users can be assigned to one or more roles. The thin lines denote these connections are easily made or changed

Users Roles Permissions

The ACL Rules assigns permissions to each role. The thick arrows denote that these do not change often and can demand more technical knowledge to set up.

RBAC1

Joomla accommodates this. If we treat a user group as a role, then we have what we need to implement role-based access control.

Users are assigned to one or more roles. Each role is assigned

to a set of permissions

1.5 vs 2.5/3.x

1.5 vs 2.5/3.x

1.5 delivered a totem-pole approach to groups.

2.5 allows for sibling groups.

1.5 vs 2.5/3.x

1.5 has a fixed set of groups

2.5 allows us to create groups as we need them……and to place them wherever we want within the group hierarchy.

1.5 vs 2.5/3.x

In 1.5 a user belonged to one place on the ‘totem pole’ of groups.

In 2.5 we can assign any user to any combination of groups

1.5 vs 2.5/3.x

In 1.5 the permission were pre-assigned are rather fixed for each group

In 2.5 a component can declare the actions, and each actin can have its own permissions settings. We can set a permission as we want: on whichever actions for whichever groups.

1.5 vs 2.5/3.x

Since 2.5 we can set permissions at the category and object levels.

1.5 vs 2.5/3.x

And the new ACL allows developers to declare a rich set of actions that arespecific to the component.

1.5 vs 2.5/3.x

Whereas the old ACL gave us only 3 access levels …that imposed levels (no sibling items) ...and we could not change

In the new ACL we have real access lists …we create as many as we want …each item is a sibling (no imposed levels) …we can configure each as we want/need

The new ACL offers so much more than the old one did.

So why does the 2.5 and 3.x ACL look so similar!?!

1.5 2.5/3.xThe new ACL offers so much more than the old one did.

But to help users understand the ACL, the out-of-the-box configuration mimicked what users knew from 1.5.

…The unintended consequence is that many 2.5 users maintained their 1.5 mindset about the new ACL. But the new ACL was not meant to be limited to that!

1.5 2.5/3.x role-based

The role-based approach exploits the new features of Joomla’s ACL and it leads us to a different look.

What does a role-based system look like

just enough

What does a role-based system look like

isolated and typically non-overlapping

What does a role-based system look like

assigned to more than one role

What does a role-based system look like

share the same role

What does a role-based system look like

business concept

of its roles

name,capabilities

Each user can be assigned his own set of roles.

What does a role-based system look like

easily added, removed, or transferred among users

What does role-based buy us?

What does role-based buy us?

Security – for the client and stake holders

principle of least privileges

What does role-based buy us?

Usability – for those using the CMS

What does role-based buy us?

Flexibility

– as staff and staff assignments change over time

What does role-based buy us?

Ease of Comprehension– for business people using the CMS

A staff person does not have to understand ACL and permissions to quickly and easily assign a person to a role.

Setting up a role-based system

roles

permissions personalization

Now its time to look at the other side of the coin – using roles to reflect personalization of the user’s experience with the CMS.

Role-Based Joomla!We can leverage roles to reflect what the user sees when logging in to the backend

County Auditor’s dashboard

I built a site for a county that had over 20 departments. Each department was represented by a role (user group). When a staff member logged in, she would see the quick links for the department to which she belonged.Here is what the staff for the Auditor/Treasurer would see.

Auditor’s department pages

And each link led to a list of items with the filter preset to those of that department’s category.

Auditor’s JCE settings

The JCE editor was preset so that its image manager and document manager would give that user access only to the directory dedicated to that department.

A user could not add or delete assets only for any department but his own.

County Sheriff’s dashboard

Here is the view of the Sheriff’s department, which contains two additional roles.

County Webmaster’s dashboard

The person who is a site’s webmaster usually includes multiple administrative roles – including access to site reports.

beforeafter

HikaShop product pageOne can use roles to show only the form fields that a user needs to access. This usually takes a little bit of code in a layout override.I am developing a tool that allows a site integrator to configure this per role, without having to code the solution.

Setting up Roles

I first create a base usergroup that grants nothing but access to the backend. All backend roles will extend from this.

Role-based implies:

Then I create a user group (white) for each role, and an access level item (red) for each of these role-based user groups. Each of these access level items includes only it’s associated user group.

Typically, a role will be associated with only one component. Set the permissions on this role only for that component and for that role’s user group. Leave all other permissions as inherit.

Create an access level item for each role. For each of these access level items, assign it to include only the corresponding user group.

My preference is to prefix each role-based access level with a tilde ~. It helps me navigate the dropdown list when assigning an access level.

Then I create an admin module of quick links for each role. The access level for each of these access levels is set accordingly.

The admin template uses module positions, so identify the position to use for each of your role-based admin modules.

As a result, one sees only the quick links modules for the roles to which she is assigned.

assignment

Often overlooked is the important role of user manager. This itself should be a role, and whoever is assigned it has the power of your ACL in his hands.

User ManagerLet’s make a role for User Manager…

Now, anyone assigned to just the role of User Manager will see this

…and have access to set things like password, a changed email address, user groups, the backend template that a user should see, etc.

Personalization of the client’s user experience is a major part of the work that I’m exploring and developing through the iCue Project.

Areas to personalize

dashboard: personalized linkspre-filtered listedit screenedit toolbarmedia manager

Dashboard - links

Pre-filtered lists

tailored edit form

tailored edit form

This is Form Field Manager, a tool being developed through the iCue Project

Edit Toolbar

iCueProject.com

a suite of extentions to provide role-based personalization.to be available through the iCue Project

Role-Based ACLto improve content management

Randy Carey

iCueProject.com