In response to the original question:
jmonarch wrote:Allow for Advanced User Privileges
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.
- 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
I wish to propose a version 1.6 ACL security system based on version 1.5 Groups and Access Levels. It would minimize the impact on the Joomla! Framework, interface, and what is the Joomla! concept of security, while allowing a rich new feature, version 1.6 Groups, as an optional addition to version 1.6 security. Version 1.5 groups and access levels would be combined into the same concept of version 1.6 Roles, (Access Levels in 1.5 are basically an abridged, ie: shortened, version of 1.5 groups). One new component, Groups, would add 2 new steps to the access decision, and allow administrators to change the user’s level of control over specific objects, ie: Sections, Containers, Articles, Components, Modules, Plug-ins, etc...
1. Develop user ROLES based on the 1.5 version of groups. In version 1.6, keep all the current 1.5 groups. Add the Role “Public” to include that Access Level, and eventually “Custom” for extenders. Give guests (visitors) that have not logged in to your web site the automatic role of “Public” as well, ie: minimum changes for objects from 1.5 Access Levels to 1.6 user Roles.
2. OBJECTS, (Sections, Containers, Articles, Components, Modules, etc…), should replace the current Access Level, (Public, Registered, Special) for the same version 1.6 Role. Default user control for objects should be based on the 1.5 definition of what the 1.5 groups allowed. (Minimum retraining and reconfiguring when updating to 1.6)
3. GROUPS should be able to be added optionally by the site administrator in order to change the default CONTROL, (View, Edit, Change, Delete), and default ACCESS, (Grant, Deny), for a user’s role as specified in User Configuration. Groups are made up of a list of users and a list of specific objects which are to be acted on. For each object the group then specifies: if access should be granted or denied, and a role level if something other than the default. When granted access, the user will be given control of the object to the control level defined by the higher of the group’s or the user’s own role level. If the group denies access, and the user has a higher role level than that defined by the group for that object, then the denial does not apply. (The Group component should show specifically which users will not be denied access to the object regardless of the group setting for denial.) For access denial to apply, the role level specified must be greater than the minimum of the object’s default. The user role for denial of access should never be allow to be set to super administrator, and probably should not be allowed for grants either. Thus Super Administrator would have default access to all parts of the system since objects cannot have a higher minimum level of access than Super Administrator.
4. Complexity: behind the scenes of objects and how minimum roles are to be applied to access and control. In order to apply 1.5 group behaviours to 1.6 objects, each object must belong to a type that defines if a user is given access on the front-side or backside, and to what level of control a user has for Select, Insert, Update, and Delete, ie: you can think of these as Public/Registered, Author, Editor, and Publisher on the front-side if your not familiar with database terminology. Without explaining the whole thing, version 1.5 groups and 1.6 Roles state which one particular level a user has. In order for 1.6 Roles to work, each object has to have a grid of which user levels are required for each row (front-side, backside) and column (Select, Insert, Update, Delete). By default, 1.5 Access Levels set the required level for Select of an object on the front-side. Joomla!’s framework specifies an objects behaviour by which specific user groups in 1.5 are required for each of these grid positions based on the objects type. (I’m not into Joomla!’s framework, so I can’t say if this grid is hardcoded or based on a database table. Version 1.6 ACL in this proposal will require a database table.) When a user requests access and control of an object, the web site will determine which row is used, and the comparison of columns will determine which types of actions the user can perform on the object in that web site. Access is granted to the user’s request if he has the same or higher role as required by the object and the type of action to be performed. Changing the 1.6 role level, ie: the 1.5 Access Level, for the objects “front-side / select” user role requirement, should thus slide the entire tables default user role level requirements up or down for each row and column. If there is a real need for creating another component to change the behaviour levels per row and column, then add it later or leave it to the extenders to open this up. (Yes, groups could be extended to include it, but its complex enough as is and you want something that will change the default behaviour for the object). If the Access Level “Special” could be hidden or removed when updating to 1.6, it would be great. Anyways, it should not be allowed as a choice for 1.6 Users or Groups.
5. Use the same name for roles in 1.6 as the present groups in 1.5 in order to avoid confusion. Develop the basic rights based on the present 1.5 group restrictions and connect them to each respective role. Version 1.5 users will upgrade directly to 1.6 Roles, and thus groups are not a necessary when upgrading to 1.6. It would be helpful to be able to change roles on several objects, such as modules or menus, by checking all or a few of them in a list and giving them a common minimum role level from the menu line without having to edit each one individually.
6. Keep Joomla! security in the framework. Don’t require extensions to perform basic security checks for standard objects, ie: articles, but allow them to add system security checks to objects created via components, modules, etc… Joomla! determines if a user has access to JEvents. But JEvents can use the system ACL’s to determine which events a user can see, change, delete.
7. How access and control is determined:
a. The site configuration must determine if by default, grant access should be given priority over denial of access, or the other way around. This will change the order of point “b” and “c” below.
b. Has the user been included in any group which grants specific access to the object and what is the maximum role specified by any such group? If YES, then the user is granted access with the greater role level of the user’s own role or the maximum role level set for that object by any group the user belongs to. Otherwise continue to the next rule.
c. Has the user been included in any group which denies specific access to the object? If YES, then access is denied unless the user’s own role is greater than the maximum role level set for that object by any group the user belongs to. Otherwise continue to the next rule.
d. If none of the rules above apply, then the user’s role level must meet or exceed that of the object’s default minimum role for access. If YES, then access is granted with the user’s own level of control, else denied.