Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Role Based ACL

4,193 views

Published on

A review of the mechanics behind Joomla's ACL, then a discussion as to how one can leverage a role-based access control system through Joomla - to improve the user experience for those managing the website and its content.
Please open the tab below to view my NOTES PER SLIDE.

Published in: Technology
  • Be the first to comment

Role Based ACL

  1. 1. Role-Based ACL to improve content management Randy Carey iCueProject.com
  2. 2. 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.
  3. 3. 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…
  4. 4. 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.
  5. 5. I’ll start by explaining the ‘mechanics’ of Joomla’s ACL.
  6. 6. Then I’ll explain how permissions are calculated.
  7. 7. Then we can move on to Role-Based. What is it? How is it set up?
  8. 8. I’ll show how roles allow to create a personalized user experience
  9. 9. Then I’ll show how to set it up in Joomla.
  10. 10. Then I’ll reference a few tools that make this process easier
  11. 11. ACL Mechanics
  12. 12. 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.
  13. 13. 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.
  14. 14. 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.
  15. 15. 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.
  16. 16. 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.
  17. 17. In contrast to permissions, all resources reference access levels. Also in contrast to permissions, each resource references one-and-only-one access level.
  18. 18. 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.
  19. 19. 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.
  20. 20. One more look at the ACL diagram.
  21. 21. 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.
  22. 22. Permissions (& actions)
  23. 23. Permissions (& actions) Permissions are managed by the ACL, but for logical reasons, the component is responsible for three things. Let’s look at those…
  24. 24. 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.)
  25. 25. Permissions (& actions) 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.
  26. 26. Permissions (& actions) 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!
  27. 27. 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.
  28. 28. calculating permission Now we look at how the ACL calculates a permission.
  29. 29. 1. for a particular action
  30. 30. 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.
  31. 31. 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.
  32. 32. 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.
  33. 33. 1. for a particular action 2. Each of the user’s groups 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.
  34. 34. 1. for a particular action 2. Each of the user’s groups 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
  35. 35. So let’s look a permission calculcations from a different data model…
  36. 36. 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.
  37. 37. 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
  38. 38. 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 not undo the Deny on the category. When the component is allowed by a Deny is set inside it…
  39. 39. ACL Manager is a great tool for helping you see the results of your ACL settings.
  40. 40. RBAC1 Let’s look at how Role-based ACL looks
  41. 41. 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.
  42. 42. 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
  43. 43. 1.5 vs 2.5/3.x
  44. 44. 1.5 vs 2.5/3.x 1.5 delivered a totem-pole approach to groups. 2.5 allows for sibling groups.
  45. 45. 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.
  46. 46. 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
  47. 47. 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.
  48. 48. 1.5 vs 2.5/3.x Since 2.5 we can set permissions at the category and object levels.
  49. 49. 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.
  50. 50. 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
  51. 51. 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!?!
  52. 52. 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!
  53. 53. 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.
  54. 54. What does a role-based system look like just enough
  55. 55. What does a role-based system look like isolated and typically non-overlapping
  56. 56. What does a role-based system look like assigned to more than one role
  57. 57. What does a role-based system look like share the same role
  58. 58. What does a role-based system look like business concept of its roles name, capabilities
  59. 59. Each user can be assigned his own set of roles.
  60. 60. What does a role-based system look like easily added, removed, or transferred among users
  61. 61. What does role-based buy us?
  62. 62. What does role-based buy us? Security – for the client and stake holders principle of least privileges
  63. 63. What does role-based buy us? Usability – for those using the CMS
  64. 64. What does role-based buy us? Flexibility – as staff and staff assignments change over time
  65. 65. 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.
  66. 66. Setting up a role-based system
  67. 67. 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.
  68. 68. Role-Based Joomla! We can leverage roles to reflect what the user sees when logging in to the backend
  69. 69. 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.
  70. 70. Auditor’s department pages And each link led to a list of items with the filter preset to those of that department’s category.
  71. 71. 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.
  72. 72. County Sheriff’s dashboard Here is the view of the Sheriff’s department, which contains two additional roles.
  73. 73. County Webmaster’s dashboard The person who is a site’s webmaster usually includes multiple administrative roles – including access to site reports.
  74. 74. 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.
  75. 75. Setting up Roles
  76. 76. I first create a base usergroup that grants nothing but access to the backend. All backend roles will extend from this.
  77. 77. 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.
  78. 78. 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.
  79. 79. Create an access level item for each role. For each of these access level items, assign it to include only the corresponding user group.
  80. 80. 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.
  81. 81. Then I create an admin module of quick links for each role. The access level for each of these access levels is set accordingly.
  82. 82. The admin template uses module positions, so identify the position to use for each of your role-based admin modules.
  83. 83. As a result, one sees only the quick links modules for the roles to which she is assigned.
  84. 84. 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.
  85. 85. User ManagerLet’s make a role for User Manager…
  86. 86. Now, anyone assigned to just the role of User Manager will see this
  87. 87. …and have access to set things like password, a changed email address, user groups, the backend template that a user should see, etc.
  88. 88. Personalization of the client’s user experience is a major part of the work that I’m exploring and developing through the iCue Project.
  89. 89. Areas to personalize  dashboard: personalized links  pre-filtered list  edit screen  edit toolbar  media manager
  90. 90. Dashboard - links
  91. 91. Pre-filtered lists
  92. 92. tailored edit form
  93. 93. tailored edit form This is Form Field Manager, a tool being developed through the iCue Project
  94. 94. Edit Toolbar
  95. 95. iCueProject.com a suite of extentions to provide role-based personalization. to be available through the iCue Project
  96. 96. Role-Based ACL to improve content management Randy Carey iCueProject.com

×