Page 1 of 6

[15]Access Management in Joomla! 1.6

Posted: Sat Feb 16, 2008 6:38 am
by jmonarch
Allow for Advanced User Privileges

1. Introduction

Many websites require a tiered user permission system, in which specific user groups are given different permissions and access to other parts of the site that a traditional user may not be (i.e. a paid site, which has "premium" content, but also free options). This paper looks at a method for which administrators could create usergroups, and set permissions including limiting access to modules.

2. Scope
  • Administrators can create groups, and limit access to specific modules on a group by group basis
3. Technical implementation
  • All in the backend, users see nothing except what they're allowed
  • Allow for automation. Example, if users pay for access, then they're automatically placed in a special group
  • Allow for an unlimited number of groups
Thank you.

Re: User Permission Abilities

Posted: Sat Feb 16, 2008 7:05 am
by gomango
Great recommendation!

If this feature was developed following the current access level scheme, then there would minimal education required for end users. It would simply be an expanded function of whats already there.

I can think of two administrator components that would need to be added.
Groups administration--> Ability to add and remove custom groups, and add and remove users from those groups.
Access level administration--> Ability to add and remove custom access levels, and group components, modules, and plugins under each custom group.

One change to the current system would be that when selecting access levels, the group selected should not inherit permissions from child access levels unless those groups were selected as well. This would allow webmasters to conceal "benefits of registering" stories, and other guest greetings that logged in users need not see.

Re: User Permission Abilities

Posted: Sat Feb 16, 2008 9:05 pm
by jmonarch
Thanks. This feature's intent is to make community sites a lot more featured, as easy to manage for the admins.

Re: User Permission Abilities

Posted: Sun Feb 17, 2008 5:10 am
by jimesmythe
This component would be great for 1.0 and 1.5. I constantly, when creating new sites, need a way to make "User Access Groups" with no good way to do so. JACL is a great example; however, it changes core files and does not work with all extensions.

I want better ACL

Posted: Sun Feb 17, 2008 6:59 pm
by spike00
;D Just to demonstrate I read the wiki page :D

hmmm ok stop joking


(Please forgive my bad english, I'm italian)

Recently I've been charged to find a solution for some sites for associations (like lions, rotary, jci, ecc...)

As you may know, these associations are organized at various levels (international, national, district, local chapter, ecc...)

Well, the major issue when building sites for these kind of organizations (but it's similar with big companies) concerns user management, roles and permissions.

Here I hope I can make a brief digression about my recent experience in finding a good solution for my needs, without hurting anyone (I think is good to points out some (ehm) points).

We all knows that Joomla! at the moment has not a strong and granular ACL management, so I looked at Drupal: what a nightmare. It's quite good for a dev target, not comparable to Joomla for standard users. But, awful surprise, his so magnified acl doesn't allow to assign a user the permission to manage just a specific 'group' (no specific meaning of the word group, consider it as a subset of the whole users) of users. (Some threads in their forum stated this).

Considering this and many other things, I decided to look at EzPublish.
Wow, a 1900 (about) pages in the developer manual...
Here everything looks clean, easy (quite, but not at Joomla! level) and well documented.
Best of all, finally a good ACL.
Why good?
Because it's really granular, not like Drupal.

So which is my first point for a good ACL? - WHAT

The permissions work not only at general 'functionality' level (ie: not only access to content, components (in J! environment) or modules (in Drupal environment) and so on., but also at function level (inside the 'component')!!!

Unfortunately I believe (community opinion needed here!) that to achieve such a kinf of ACL has huge impact on these fields:

1) Backward compatibility
2) Performance
3) Amount of work needed (related both to core and to external components)
4) User friendliness in creating roles and assigning permissions (but maybe some standard roles could be created with assigned permissions, allowing this way 'normal' users to manage their Joomla sites as they always did, so only who wants to go deeper will get into acl stuff).

Resume of what:

1) Ability to create Roles (with 'sub-roles', meaning hierarchy).
2) Ability to assign permissions to roles (evaluate inheritance between roles and sub-roles)
3) Scope of permissions: functions (a dream?). This is (quite) easy for simple content, 'cause usually there's only view, add, edit, delete (and publish... and, going further in Joomla environment, archiving), but for other 'ojects' could be needed an extension (example: user management, assign, change, revoke permissions).
4) I don't know how to express better next feature: Filtering
Point four concerns what in phpGacl is named AXO (Access eXtension Objects) (example: Role A has the permission to add, edit, delete 'objects' of 'type' xxx. Objects could be articles, type could be category. But also, objects could be users and type could be Role, or Group or whatelse).


Hmmm... very hard to say in details. Maybe a search could be carried on to find best practices (especially regarding performance).

Maybe this kind of improvement should be carried on considering also what included in the user management white paper

This way we could easily write code to manage different kinds of registration, having specific roles assigned to registered users based upon the different kind of registration taken.

Hope this all makes sense.

Thank you.

Ouch, I forgot 2 things not related to the matter:
1) Ezpublish, it's strange (incredible) how late they're coming to php5 (about php5 and php4, I read Wilco considering a problem the lack of compatibility with php4 about a white paper around here: I don't agree (If I understood well) since php4 is no more supported (in development) so why worry? I believe every ISP will soon remove php4 from their offer).
2) From Joomla!1.0.x to Joomla1.5.x has been made an incredible work toward management semplicity, even increasing the power of joomla! (there's no comparison with other os cms).

Re: I want better ACL

Posted: Mon Feb 18, 2008 11:45 am
by tsimpo
he permissions work not only at general 'functionality' level (ie: not only access to content, components (in J! environment) or modules (in Drupal environment) and so on., but also at function level (inside the 'component')!!!
I agree

Re: I want better ACL

Posted: Mon Feb 18, 2008 1:47 pm
by spike00
Further consideration, involving ACL management, user management, taxonomy.

If we could use the concept of node and consider each 'object' (content, users, ecc...) as a node all three matters written above would be much easier to 'treat'.

Unfortunately I believe this really would have a very big impact on compatibility and amount of work needed.

User Management Expansion

Posted: Mon Feb 18, 2008 2:53 pm
by buckneri
I would like to see the ability to create a "Manager" or "administrator" and select which Components they have access to.

The example that I am working with now is that i am developing sites using the Sobi2 Business Index component and I need to give the client access to adding multiple listings from the backend without giving them access to anything else that could become damaging to the site.

I am honestly not sure how to implement it but something with just a checkbox list of components and content would work perfectly.

Jason Neri

Re: User Permission Abilities

Posted: Mon Feb 18, 2008 2:54 pm
by mikeyverbaan
I've been using Mambo, followed by Joomla for about 3 years now. I must say Joomla offers a very complete package, and just about all the components that are not available in Joomla itself, are available through the use additional components. Unfortunately, custom access levels & user groups have never really been done in a component without affecting compatibility with other components. In my opinion, this functionality is part of the Joomla core, and I would very much like to see this in the next Joomla. Compliments on doing a great job all these years!


Re: User Permission Abilities

Posted: Tue Feb 19, 2008 10:22 pm
by mtxrooster
I too would like to see this implemented (as I've mentioned several times throughout the regular forums).. I'm a LOOONNG time pn user, and last two years I've spent in DNN. When I compared Joomla to pn, which is my pref between DNN and pn) I was very excited with the fresh, professional look of Joomla, and all of it's features/abilities. I'll be forthcoming honest and say I completely overlooked the fact that there was no user permissions system in Joomla. I installed it, went to configure it, and was like, what?? Where do I set membership levels, etc..??

IMO (and I realize this doesn't affect everyone) this is the #1 thing that should be incorporated into Joomla. Practically every module/component pulls the security info from the core, so this one simple inclusion would mean a world of difference.. Access settable news, modules, and specific forum category access in an instant.. I heard rumors that this was set to be included in the upcoming 1.6, but am voicing my opinion on the matter just in case it was just that - a rumor.. IMO the lack of this one feature is the only thing holding it back from being deployed and spread over the internet like wildfire. Tru Story.

Re: User Management Expansion

Posted: Wed Feb 20, 2008 6:56 am
by Geoff

Re: User Permission Abilities

Posted: Wed Feb 20, 2008 8:21 am
by Nakebod
This is a feature where I'm waiting for for a longer period of time.
Allow/deny users to content, or even whole components/modules, sections or categories.

In my attached example I've mixed various options into 1 page, but it's just to give you an impression of how I see a possibility to create the backend of the permission system.
A more detailed example of how this could be done: 1 page per "permission item", and with permission item I mean permissions per component, per article, per section, etc...
Thats why I've added Components, Modules, Plugins.. at the top menu.
Each item gives a page like I've created already, but only with Component permissions, or Article permissions, or whatever you select to view.

Well, it's just an idea, but I'm sure Joomla 1.6 will get a better ACL then 1.0.x and 1.5.x :P

Re: User Permission Abilities

Posted: Wed Feb 20, 2008 9:33 am
by mtxrooster
The thing is, while it can be made (no offense at all to you) as cumbersome and consuming as you show in your image, the fact is, 3/4 of what we need already exists. Every (well written) component/module already has the access level feature in it. The problem is there are only three levels, and NO way to add to that, automatically or manually. You are either a public user, a registered user, or a special user. Period. Eg. of locations (not that you don't know, but just to make sure we're on the same page here):

Articles have it in: parameters/article->access level

modules have it in details->access level..

The thing is, there are only three and they cannot be modified. (public, registered, special). All that needs to be done is a component/module needs to be implemented that allows you to add/edit/remove these access levels. Then you can go about changing user access levels any number of ways.. In your user management (be it core or CB), through a possible back or front end module just for permissions, etc.. You don't need all that fancy stuff to accomplish the same task. You just need the ability to actually tap into the core three and be allowed to add your own.

Doing this simple thing would put Joomla on par with just about every other CMS out there. Content on the main (or any page) could be displayed as it is now by permission, multiple levels of access could easily be made (and could follow the 'inclusive of all below it' or a 'token key' system (where you have to have the 'access key flag' to be able to see, note this would break the scheme of the ease of Joomla and it's current three tier system, but worth the mention). And forums such as Fireboard and any other native forum to Joomla could actually be used properly, where "members" (not just people who have created accounts) can have their own private forums, be it for gaming clans or business discussion etc..

The thing is I don't (obviously) know much about programming. I dabble, but only in fun, useless applications so far. While I envision my "simply add the ability to create your own access levels" it must be fairly tough, because not only has the Joomla team not done it yet, but more importantly, no other group has done this.. Yes, there are 'hacks' out, but I mean an actual integrated module. Anyway.. That's where I see this going.. From personal experience, you aren't going to want big clunky permissions menus to wake through for each and every module/component you have. You want something that will work with the existing system and be almost seamless to install. And really, far as I know, this way is every bit as powerful as your way. Again, the only other way I could see going, that would be a huge rewrite, would be using a key-based system.. Where everything has a 'access key', and you set up your user groups (or permission levels) and assign them 'x' keys. Much easier though to just be able to add "employee" and "customer" (or whatever you want/need, say, "paid member"...) to the permissions list Joomla already has and then simply click on the content and set it accordingly ;)

Re: User Permission Abilities

Posted: Wed Feb 20, 2008 12:18 pm
by Nakebod
You don't need all that fancy stuff to accomplish the same task. You just need the ability to actually tap into the core three and be allowed to add your own.
I agree, and I don't agree at the same time :P

And of course I want to explain this.
In fact you are right that Joomla has the basics included already with Public, Registered or Special.
If you just add an option to add more groups, the result is "just good enough" imho. It does what it has to do: allow/deny access to whatever you want.

But, let's imagine a few things.
You have a large site, let's say, 200 sections, 600 categories, 5000 articles.
You want to have guests (Public), free subscribers, bronze members, silver members, gold members, and next to this, also some editor groups which may only edit a few sections or categories.

How, except by checking each permission setting manually, would you easily see if you have set up the right permissions?
I would not say that my example I've made is "the" solution, or is even close to "perfect", but it's an idea to start with.
You have an overview of each group, and you can easily see whether this group has access, or is denied the access.

In my opinion (And hopefully also others) an "Permission Overview" is a very useful addition. And maybe this can be used in addition to the suggestion you described. Would be a win-win situation? ;D

Now I think of it, Drupal got something simular as I've described here.
Just one page with the groups and all the things this group has access to, or, doesn't have access to.
And, afaik, this system is not bad.

Re: User Management Expansion

Posted: Wed Feb 20, 2008 1:46 pm
by buckneri
Yes similar. but i actually found that i could use a component that gives you the quick icons to customize a client area.

the main problem with the component is that even though i can make a manage account which has the least access and give access to a specific component through a quick link, if that component can only be accessed by administrators the quick link wont work.

therefore, even just a modification to that component so that you can limit more access that is given to the admin by default would work. that way you could start at admin level and remove access rights one by one.

Re: User Permission Abilities

Posted: Wed Feb 20, 2008 2:16 pm
by sapoku
I think the idea is good and really needed as a core feature.
Searching the forums, i founs that we are not alone on this.

My aport to this post is this.
Please visit
Its a groupware solution, with an excellent ACL.

backend admin gives permisions to wich features (add-ons) will be visible for each group of users.

If a feature gives the ability for a user to create content, it allouds the user to choose wich groups will have access to the content and also what kind of access.
(this feature is implemented only if admin allows users to manage their ACL, if not, Admin set ACL rigths to content)

Hope this is usefull.

Active Directory / LDAP Group Integration

Posted: Thu Feb 21, 2008 12:28 am
by MasterC

Joomla! 1.5 brings about the ability to authenticate against an LDAP Directory. This is an amazing integration for businesses / universities who manage thousands of users who need a seamless solution to Joomla authentication. By adding Group level restrictions/permissions Joomla will be able to essentially map existing Joomla groups to existing Active Directory groups. Assuming we have further fine grain control with regard to ACLs, this would also help in managing those ACLs.

I've already somewhat mentioned this above. Groups can provide a very simple way to allow a large selection of users specific levels of access. At the university level, professors could submit articles and approve their own, students could submit articles but not have them approved, senior faculty / vice presidents could approve all articles, and IT could be the "Master" Administrators. Even further specific groups that professors may belong to (multiple groups) would have differing permissions based on which group they belong to at the time. If a group of professors form a temporary committee to search for new faculty for example, a group could be created in Active Directory and given the ability to submit and approved articles in Category "Recruiting" only. This would give Joomla a much higher level of adoption by major institutions as well as make it highly customizable based on exterior "ACLs" without modifying much of Joomla's code / databases.

Level of Importance
The level of importance probably varies by institution and need. For large scale adoption by university-sized organizations, I believe the level of importance to be very high. However, for a personal website or blog where the LDAP auth is unlikely used, LDAP groups would probably be completely unused. Overall I think that Group integration would benefit the majority of Joomla! users.


White Paper/Feature Request - User Group ACL/Perm Revamps

Posted: Thu Feb 21, 2008 2:07 am
by sbrawner
I've read through the requests so far on this forum as they relate to groups and I've found some stuff but nothing overarching to really lay out the need in almost all cases for a revamp of this part of Joomla. I hope this works as a first draft and helps the developers.

Please see following URL for living document:

Initial draft of document is as follows:

Joomla! 1.6 White Paper/Feature request
User-Group Permissions ACL system revamp

By Scott Brawner


Currently Joomla! 1.5 provides the following classes of users:

Front end: Guest (not really a userclass), Registered, Author, Editor, Publisher
Back end: Manager, Administrator, Super Administrator

These user types (as designed) appear to be geared specifically towards cooperative blogging or basic web publishing and do not constitute a comprehensive and granular ACL system as would be required from an enterprise-class CMS.

It is not necessary for the CM Framework to provide a full set of ready-made user/admin roles for all applications, however the ACL system for a full-fledged CMS needs to be configurable and granular to a high degree. As of 1.5 there are no facilities for this built into Joomla.

While the opportunity for customization of ACLs, roles and user groups presents itself to third party developers, as far as security and modularity is concerned it really needs to be part of the core, because it touches almost every other facet of the CMS.

Examples of perceived needs:

Example 1: Company A is creating an interactive website for customer support, but needs to define roles for more than one type of registered user. These roles/groups would be used to allow or deny access to certain parts of the website based on user’s group membership.

Example 2: Company B has an inward/outward facing intranet, where internal employees and external contractors must access the same set of documentation. However there are certain documents that contractors are not allowed to access or even be aware of their existence.

Example 3: An Open Source project is collaboratively compiling documentation for their project. Many different developers are working together to compile this information. In order to categorize the documentation effectively, it becomes necessary to allow/disallow publishing to certain categories based on group membership or hierarchies.

Current status:

Currently one TPD project (Community Builder) and a few commercial projects (JoomSuite & JAccess) attempt to address the deficiencies of the Joomla! 1.5 group rights system. In addition, one component (docMan) does a passable job of circumventing the inflexibility of the current Joomla! 1.5 group system. However, the fact that they are not part of the core is causing some issues and incompatibilities with extension development and none can be considered canon in any case. Security and access control needs to be internal, modular, flexible and configurable by end-user administrators for any CMS to be considered ‘ready for prime time’.

Possible issues/challenges:

Being that the users and groups are central to any type of access system, any major changes to this core would probably break just about everything third-party… unless the current group hierarchy is not changed, but augmented. It may be possible to co-opt or integrate one of the TPD hacks currently being used in order to begin integrating a more robust ACL into Joomla!, however that might be a mistake.

Proposed Changes:

Revise the current group system to provide granularity as relates to:
  • Document Editing Permissions based on object/category/section
    File/Directory level access
    Menu Access (grant/deny based on group/role membership) granular to per-object
    Object visibility based on group/role
    Administrative access granular to functions/modules

Aside from a basic set of rights groups provided by the default install, there should be facilities for end-user administrators to:
  • Create/rename/edit/delete groups/roles
    Assign these groups/roles to files/dirs/menus/objects from a section/category level down to single object granularity.
    Establish a hierarchy for rights supersession, e.g. if a category denies and an article allows, which rights set wins?
    Orphan-checking on changes to prevent orphaned objects and/or groups.
How it would work:

There are as many ways to go about this as there are coders in the world. I’m afraid that I don’t really have the background to advise on this, but will be more than happy to discuss and revise the document.

Re: User Permission Abilities

Posted: Thu Feb 21, 2008 5:03 am
by bradnana

You are absolutely correct. Drupal should be the example app for implementing ACL. Long ago I left Mambo in favor of Drupal for exactly this reason. It may not be necessary on every site, but on sites where granular user management is needed, Drupal is generally aadopted over Mambo/Joomla!

The control level in Drupal is straightforward, full featured and easy to use.

I vote for this improvement in 1.6!

Re: User Permission Abilities

Posted: Thu Feb 21, 2008 9:33 am
by mreiter
Allow access to content according to user group is really the functionality we most need in Joomla!!!
I also vote for that in Joomla 1.6.

Re: User Permission Abilities

Posted: Thu Feb 21, 2008 10:56 pm
by hansma2go
In my opinion we need to control access in 2 different ways:

1. A role based access control (this is what we have in current Joomla implementation): each user has a certain level of technical experience/education and this determines to what degree he/she should be able to use advanced features of your system, i.e. use the editor, upload images, manage items.

2. A group based acces control: the ability to organize users in groups (a user can participate in more groups) and make groups responsible for certain areas of the site. I think particularly the group based access control should be related to categories rather than components. My suggestion would be to use both the group and the role at this level.

Let me illustrate my ideas with an example:
Suppose we have a company with several departments, special interest groups and staff members. We use our CMS to create groups and we put the manager of the engineering department in the following groups: dp_engineering, staff, sig_joomla and sig_mysql.

On our website we create an intranet section and within that section a category "Engineering Reports". For this category we would set ACL as follows:

create: user must participate in one of the groups [ dp_enigineering, staff ] or have at least the role [ Administrator ]
edit/publish: user must participate in one of the groups [ staff ] or have at least the role [ Administrator ]
read: user must participate in one of the groups [ ] or have at least the role [ Registered ]
comment: user must participate in one of the groups [ dp_engineering ] or have at least the role [ Reviewer ]

What is the impact?
We need group management screens. The current role system can stay as it is, it will only be extended by a group system. At section and category level we need multiselect possibilities for selecting the groups.

Nice to have...
It would be nice if Community Builder profiling would be integrated and it would be possible to see in which groups a person participates. I would like to define one or more group leaders for each group, which have the ability to add existing accounts to their group, or remove them. Maybe even create new accounts etcetera, but this should be optional. A group leader would like to send e-mails to his group, and an Administrator would like to do some mass mailing to certain groups. Maybe the publishing of items should allways be delegeted to the group leaders. Then we wouldn't need the ACL for edit/publish.

Re: User Permission Abilities

Posted: Sat Feb 23, 2008 11:37 pm
by df23
I have just spent today at a seminar of webmasters where i gave a demo of Joomla! When asked by one delegate what is the biggest thing that Joomla cant do my answer was that it has a woefully inadequate ACL. This proposal should be a must have in version 1.6.

For my site I am specifically looking for greater control over who can author/edit/publish site content. I have specific articles on my site which i would like some people to be able to edit but to have their editing authority restricted to just those articles. The implementation of a user group based security control would satisfy this requirement. I am assuming that it would be possible to control access rights at the section level, inherit/override within categories and inherit/override with articles/items. I think that this would require a publisher to be able to set the editing access rights on new articles which they publish but i have no issues with this. An administrator would be required to amend the people assigned to access right groups.

Whilst initially 3rd party products would not use the new user access groups I am sure they would integrate this into their products over time. It would be an evolution but we need to get user access to the core product managed better as that big first step.

Re: I want better ACL

Posted: Sun Feb 24, 2008 2:34 pm
by VanCrey

I think there is already a ACL in development, which covers your requirements. With Joomla 1.5, the table structure in the DB for the ACL is already available and it is very powerful to define anything as wished.

The Problem so far, the Rules for the ACL Check in Joomla are mainly fixed definied in PHP and I also have used this for my developments, because the DB acl tables is not yet really used.

My suggestion

1. Joomla ACL Specification

We need a specification or better definition how developers can restrict commen situations. If we have no common way, it could be really cost a lot of work for all developers.

1. How to restrict general "Read, Write, Change" operations for extensions

If general "Read" is not allowded, the component should be completely unselectable or hidden by the Joomla Framework itself and not by the extension developer! This allows to give access to the Administration Page for all people using the neccessary rights and also hide elements for such as Managers.

2. How to restrict "Read, Write, Change" operations for different entity elements in a extension.

As Example, my CV Tool Component has following Entities: CV, Skill, Skill Category.

3. How to restrict "tasks" & "view" operations

Allows an overall operation in a component. If not rule is definied, it should be allowded! If the extension is developed right, it should be sufficent using the restriction options before!

4. How to define generic rules for entries of an entity. As Example, the individual "contact" of the entity "contact".

2. Framework Extension

There is already a JUser::authorize() Method. This method is powerful, but also a little bit confusing for not so well informed developers. It took me some time to understand it myself!

According to my listing, we probably need following additional methods, which indirectly call the authorize method

JUser::authorizeExtension($extension = $mainframe->scope, $userid = [currentUser])

$authorization = JUser::authorizeExtension("com_media", $userid)

This method is always called by the Joomla Framework, if the extension should be shown on the current page. It can be also called by extensions!

JUser::authorizeEntity($entiy, $extension = $mainframe->scope, $userid = [currentUser])

$authorization = JUser::authorizeEntity("category", $userid)

Return value depends on rule definition. In my case, I want a list of "categories", but dependend on the ACL, I can see only my "own" or "all".

if( $authorization == 'own')
<handling for own entities>

if( $authorization == 'all')
<handling for own entities>

The optional $userid is provided to simulate the access rights for a specific user if it differs to the current loggedin user. If the $extension is not explicit setted, the $mainframe->scope value will be used.

3. Installation procedure changes

Allow Extensions to define ACL Rules in the Install XML file or in a separated ACL.xml file, which will be evaluated during the install process. If the ACL definition clashes with existing entries, the installation fails. It should be not possible, that a installation overwrites or changes existing rules for other joomla parts!

If a extension is uninstalled, the ACL should be set to "inactive". This needs a editional column, that allows to set a flag! This is imporant for the generic rules for individual entries or in other words, we don't want to loose or timeconsuming work if we only reinstall or update exentsions.

Those changes do not require a change for existing extensions - if nothing is definied for ACL, only the general ACL extension check rule will dynamicly generated and check by the framework.

ACL XML suggestion

<acl-definition section="com_media">
<aro type="entity" value"article">
<axo type="users" value="Administrator" recursive="asc" result="all"/>
<axo type="users" value="Administrator" recursive="dsc" result="own"/>
<aro type="entry" value"article-entry">
<axo type="users" value="{owner}" result="write" readonly="true"/>
<axo type="users" value="Registered" recursive="asc" result="read"/>
<axo type="users" value="Ower" recursive="dsc" result="write"/>
<axo type="users" value="Editor" recursive="dsc" result="change"/>

Rules for individual Users cannot be definied using the XML structure, because the extension can not know anything about exsiting users, but it can be definied by the Administrator using a specific interface (next point).

3. Interface Extension

Provide an Admin Component, which allows to modify the rules.

The attribute "value" of the <axo> element in the definition can be changed by the frontend, if the readonly is not setted. The provided options of the "value" depends on the attribute "type".

Value "users" : provides a list of User Groups or/and individual users.

Placeholders are definied like {owner} or {modified_by}, which are replaced dynamicly by the framework. This allows to define rules for the "owner" of an object, who to not have general rights.

4. Conclusion

With this development, we will be able to get a "reduced" view on the more powerful ACL structure, but it allows us to define a common "simple" process for all extension developer without restricting people to use the full ACL features. This makes it possible to write a common scecurity managment interface. We can easly define rules for articles, contacts, components, ... and provide a interface for it.

Re: I want better ACL

Posted: Sun Feb 24, 2008 6:26 pm
by spike00
Hi VanCrey,
thank you for your indeep analysys.
I made some searches about acl methods and found that there are not so many approaches to the problem.

Best of all, I found that ACL is just one of them, so firstly we should know if (as it seems but I didn't checked the 1.5 code about this) the dev team already choose the way to follow or not.

This is what I found:

1) phpgacl (ok this is what it seems to be partially implemented, or not? And the method foolowed by VanCrey in his analysys)

2) Liveuser by PEAR (package: , tutorial: , interesting article by David Toshack - Typo3: ... Management)

3) RBAC by Tony Marston -Radicore (possible licensing issues) - ... ntrol.html

4) RBAC by Ben (interesting and he seems to be available to help for integration, as he wrote on june 2007) - ... _system-3/

Once decided how to proceed, the ideas of VanCrey are a good point regarding backward compatibility.

Re: I want better ACL

Posted: Sun Feb 24, 2008 7:32 pm
by VanCrey

yes, phpgacl is since 1.5 partially integrated and all features are available using the class JAuthorization, but thats not the point. My point is about how to use it, so that we are able to cover & manage the whole joomla app. by a ruleset.

The current JUser::authorize() check is a good start, but it not really used. We need a config xml file with a common definition, so that a frontend tool can be set on the top. Joomla should itself handle a minimum of security checks for each extension, so that the Admin can allow a Publisher to login to the admin page - without getting access to individual config elements.

Re: I want better ACL

Posted: Sun Feb 24, 2008 10:37 pm
by Hackwar
phpgacl is shipped with Joomla and is "integrated" in the DB etc. since Mambo 4.5.

Re: White Paper/Feature Request - User Group ACL/Perm Revamps

Posted: Mon Feb 25, 2008 1:27 pm
by sbrawner
Wow, crickets.

Re: I want better ACL

Posted: Thu Feb 28, 2008 11:23 pm
by VanCrey
I took a closer look at the current used phpacl integration


The PHPGACL is only partially integrated. The most parts of the required DB tables are missing. There is only a "Simple" ARO, ARO Group structure used. The complete ACL, AXO and ACO part is missing.

ACL Short Introduction
If you see the ACL the first time, its quite complicate. I will try to get a short introduction, which makes it easier to discuss the topic.

ARO = Access Request Object

An entity (such as a User), that is requesting an action to be performed

ARO tree

Defines a hierachy of Groups and AROs (such as User Groups)

ACO = Access Control Object

An action that are requested to be performed or in other words: a thing, that we want to do using a specific object (AXO)

AXO = Access eXtension Object

The Objects, that we want to assign restricted access for specific AROs

What we need

- Creation of an unlimited amount of Groups: "Guest", "Registered User", "Advanced Registered User", "Employee", "Editor Newsflash", "Editor Banner", "Contact Manager", ....

- Assignment of Users to one, two or more Groups at the same time such as: Tom is Member of "Employees" and "Editor"

- Access Control assignment to each single entity (specific Article) and/or all entities of a specific type (all Articles)

Lets bring it together with PHPGACL

ARO(-Tree) = Users / User Groups
AXO = Module Extension, Component Extension, Article(s), Single Menu Item, Contact(s), ...
ACO = edit, save, load, display, show all, show own, ...


Can Tom or a a Administrator (ARO) see (ACO) all Articles from the category Newsflash (AXO)
Can a Administrator (ARO) see (ACO) the Contact Menu in the Admin Page (AXO)
Can a Administrator (ARO) open/click (ACO) the Contact Menu in the Admin Page (AXO)


The whole PHPGACL is very powerful, but on the other side it gets to hard to manage it (for the beginning). I suggestion to restrict the appility to build a hierachy of AXO (Objects) and ARO (Group/Users). It's easier to realize the application by restricting the hierachy functiontional to only one single level - we can define a Group and assign users, but we can not define a Group, which consist of a Group. The same situation for the AXOs, we can group articles together (= categories or sections ), but not categories in a category.

On the one side, its quite nice to have more control, but its getting to complicated for the developers AND the users. Try to think in a third dimension and you probably get headache. I also expect a performance issue.

Influence for the existing version

1. Integration of all PHPGACL tables

2. Replacement for the functionioanlity behind the table "jos_groups" (=Public, Registered, Special) through a entry of jos_core_acl_aro_map.

3. Limited basic ACL checks through Joomla for Module Instances and Components.


By replacing the "Public", "Registered", "Special" functionality we do not really have to change much and its just the same functionality like before without calling the ACL functions. Its a simple group check for all available groups - if possible only for the group type (section) "users".

As I alread wrote in my previous posting, the ACL check should be done for show, hide and disable general components and modules. Its very important to get a better more granular control also for the existing functionality.


A Menu Item "Statistics" or a Wrapped "Web-Hosting page" is show on the homepage, but it should be nit visible for normal registered Users. It should be only visible for "managers"

Another Example

The Admin page should also allow to give Publisher access to the Administrator Page, but we don't want to show hime all menus or show him only disabled menues (the choice should be done through the ACL definition).

- Components
- Module
- Articles

Re: White Paper/Feature Request - User Group ACL/Perm Revamps

Posted: Sat Mar 01, 2008 10:56 pm
by VanCrey
We already have a thread, where we have a more technical discussions.

Take a look here

There Idea is to better integrate the current used Access Control "ACL" based on PHPGACL. There are already partially Access rules. There current rules are hard coded, the PHPGACL is only partially available and we do not have a Joomla Component for creating and changing rules. If the thread above is approved, we will have what you / we want ;)

More user control

Posted: Wed Mar 05, 2008 5:15 pm
by SpacePyrit
I have noticed the default Joomla! user panel is very limited as to user permissions. A checklist type box in the user control panel would be great. This box would contain different permissions concerning users. For example:
  • Can Veiw Articles
    Can Create Articles
    Can Publish Articles
    Can Edit Articles
    Can Insert Images
    Can Insert Links
Also there would be an admin user box. This box would set user permissions concerning the admin panel. This could be helpful in solving problems. Where a user can veiw your back-end but not edit, publish, delete anything.

Also there should be more optimization concerning What content a user could veiw, edit, publish, etc. I would like to allow certain user to veiw only certain articles and edit particular articles, and publish articles in a particular category and section.

This is just a suggestion based upon what I would like and what others are having trouble with.