Role Based ACL

Role-Based ACL
to 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 experiences
for 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

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 roles
through 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 presents
us 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 that
Resource’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 are managed by the ACL,
but for logical reasons, the component is responsible for three things.
Let’s look at those…

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.)

1
But many developers can do better
by offering actions specific to the
component’s type and data.
Shown to the left here are the rich set
of actions provided by EasyBlog.

1
2
The 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.

calculating
permission
Now we look at how the ACL calculates a permission.

1. for a particular action
2. 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.

3. 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.

3. 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 –
The Denied items are denied, but
All other items and those that are
created later will be allowed
All items denyed –
Even an Allow on the item will not
undo 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 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 are
specific 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.x
The 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?
Security – for the client and stake holders
principle of least privileges

Usability – for those using the CMS

Flexibility
– as staff and staff assignments change over time

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.

before
after
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.

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 links
 pre-filtered list
 edit screen
 edit toolbar
 media manager

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

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

Role Based ACL

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a Role Based ACL

Similar a Role Based ACL (20)

Más de Randy Carey

Más de Randy Carey (7)

Último

Último (20)

Role Based ACL

Notas del editor