We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 3749
    • 24,544 Posts
    I did some work on a proposed Security System for MODX 3. I tried to incorporate the best features of Evo and Revo in a simpler system that could be built on top of the current Revo permissions architecture. Ryan suggested that I post my ideas here for discussion, so here they are (warning, it's a long post):

    PERMISSIONS

    My views on this have changed some since I last expressed it and my proposal is more complete.

    I've really thought a lot about this, since we all know the current system seems to be unlearnable for the vast majority of users. It seems straightforward to me, but I hear from fairly intelligent users who have read the official docs, read my book, read the *many* pages at Bob's Guides several times, watched my video, and tried for days to set up a fairly simple Permission system and still don't get it.

    It seems like they are not getting the concept of "protection" and learning what's protected and what isn't, but people understood the Evo Permission system, which uses the same concepts, and I can't think of any alternative that would work.

    My reluctant conclusion is that they *do* get it, but are failing due to the complex interaction of Policies, Contexts, Roles, and Minimum Roles. IOW, they try a hypothesis which is correct, but their implementation of it is flawed so they conclude that it's incorrect. This leads them to a hypothesis that is incorrect, but may work partially so they try to tune it. This goes on indefinitely.

    I have a solution that simplifies things considerably, but still allows you do everything you can do now except have inherited Permissions within a User Group, which I don't think makes anything doable that you can't do without it. I also think this solution would fit well on top of the current underlying security architecture.

    Here is my suggested solution:

    First and foremost, get rid of the current Roles and change the name of Policies to Roles. IOW, a Role is a collection of Permissions like in Evo, but users can have different Roles in different User Groups. The problem with Evo is that a user can have only one Role, but that problem goes away if a user can have a different Role in each User Group.

    Everyone intuitively understands that if the Editor Role has certain Permissions, a person with that Role in a User Group will have those Permissions. For some reason, separating the Role from the Permissions (and adding in the concept of Minimum Roles) is making people's heads explode.

    IMO, we don't actually need inheritance of Permissions with higher authority numbers, so I would do away with authority levels altogether. I'm sure it's used by someone, but I don't think it really provides anything except convenience and it increases exponentially the odds that a security scheme won't do what you expect it to. As long as users can have different Roles in different groups, you can still do anything you want, and it's much easier to understand and debug.

    Instead of Context Access ACLs, create a set of Manager Access Permissions that have nothing to do with what you can do with Resources, Elements, or users. These would allow users to customize what is seen in the Manager and nothing else. If the user can't reach the Create/Edit Context panel, they can't create or edit a Context. All object Permissions (save_document, save_snippet, etc.) would go in the Roles used with Resources, Elements (including property sets), and Users. The short Permissions (save, delete, duplicate, etc.) would be gone.

    So there would be four basic Role Templates: ManagerTemplate, ResourceTemplate, ElementTemplate, and UserTemplate. The Roles would be edited on four separate grids (on tabs) with a tab for each type of Role (Manager, Resource, Element, User) and the same setup for the Role Templates, which couldn't be reached or seen without the edit_role_template permission in the Manager Role.

    This is very understandable. If you want to customize the Manager, you alter a Manager Role. If you want to control what users can do or see with Resources, you alter a Resource Role. This eliminates the common question, "why can't I see the Resource Policy in the drop-down list?" Since a Manager Role is only for customizing the Manager and doesn't have any Permissions that control what you can do with Resources or Elements, you know what you'll find there.

    If I take away save_document in a Resource Role, the person can't save a document -- period. Everybody can understand that. The down side of having both save and save_document as we currently do is the all-too-common question: "I gave these users save Permission for Resources, why can't they save Resources?" If I need users to be able to save some documents and not others, I need more Resource groups and Roles, but it's easy to understand what will happen with a user who has a Role that allows save_document in one User Group and a Role that doesn't have that Permission in another User Group. You also know exactly where to look if you want to change what a user can do.

    This would simplify the Permissions system immensely.

    There needs to be a way to control access to Contexts. Having it in the ACL entry would probably be the easiest to implement without changing the current architecture. I would only show it for Resources. For all other types of ACL entry, it would be set to 'mgr' and not shown. This prevents Element and User access to be controlled by front-end Context, but I think in the long run, allowing that does more harm than good. In the rare case where those are necessary, it can be done with snippet or plugin code.

    Hide the security Templates. In my scheme, these would be Role Templates (since Permissions are attached to Roles). These give you no added capabilities that wouldn't be handled by a change_role_template permission in the ManagerTemplate. I would let users with that permission get to them, but would not put them in the same panel as the other security Permission stuff. It just confuses people who don't really need them. They could be a separate menu item or be reachable with an "Advanced" button (that would only appear for users with edit_role_template permission). The defaults would have all relevant Permissions.

    Consider a "new Resources protected by default" option for everyone but sudo users and/or users in the Administrator group (and a similar option for Element Categories). On a site where only logged in users can see most of the pages, it's a kludge to have to create an ACL entry and install a plugin that puts all new Resources into a Resource group to protect them. One way to implement this would be to create a ProtectedDocs group attached to the Admin User Group and put all new Resources in it by default. A System Setting could control whether this is on or off. This would make it much easier to implement the common case where you want users to be able to see only their own pages. It would be nice if you could to that without creating a User Group and Resource Group for each user, but I haven't thought of one.

    Make access_permissions more granular. This is especially needed for managing users. We need to be able to create users who can manage other users but can't change the admin's password. I don't see any way to do this but to create a parallel "User Access Permissions" system just like the current Resource security system, but for managing users instead of Resources. In keeping with the proposal above, Roles based on the UserTemplate would have Permissions like save_user, edit_user, delete_user, etc., and there would be ACL entries attaching Manager User Groups to Managed User Groups. If you belong to a User Group in the Manager User Group column of an ACL entry, you get to do whatever is allowed by your Role in the group to users in the Managed User Group column. Note that there's nothing special about either kind of User Group, they're just User Groups. The two terms (Managed User Group and Managed User Group) just refer to the fields in the UserManagement intersect object (or whatever it's called).

    I've toyed with the idea of letting users have more than one Role in a User Group, either by having a comma-separated list of Roles in the users group entry or by just having extra userGroupMember objects and having the user appear on multiple lines, but I'm not sure what that would do to the implementation. I think everything I've described above could be done without much change to the underlying security architecture, but I'm not sure about this one. The idea has some advantages, but I'm not sure it's worth the cost. It's probably a bad idea.

    To summarize the main points:

    1. Current Roles and authority numbers go away
    2. Current Policies are renamed to Roles
    3. Context Access ACLs become Manager ACLs and don't have any permissions
      that directly affect Resources, Elements, or Users
    4. save_document, duplicate_snippet, etc. get moved to the Resource and Element Roles
    5. save, duplicate, delete, etc. go away
    6. User Management ACLs are added

    What I'm suggesting would cut the whole Permission system down to this:

    Manager Access
       User Group
       Role
       (Context is 'mgr' and not shown)
    
    Resource Group Access
        User Group
        Resource Group
        Role
        Context
    
    Element Category Access
        User Group
        Category
        Role
        (Context is 'mgr' and not shown)
    
    User Management Access
        Manager User Group
        Managed User Group
        Role
        (Context is 'mgr' and not shown)
    
    User Group
        Group Name (or ID?)
        Member
        Role
    
    Role
    
        Name
        Permission grid organized by area (with a filter)
        Role Template


      Did I help you? Buy me a beer
      Get my Book: MODX:The Official Guide
      MODX info for everyone: http://bobsguides.com/modx.html
      My MODX Extras
      Bob's Guides is now hosted at A2 MODX Hosting
      • 16610
      • 634 Posts
      Excellent plan and thorough thinking Bob! Simplifying the permissions system with roles that can be different in different user groups is the key. Simple, understandable and flexible enough solution. Thumbs up for this proposal!
        Mikko Lammi, Owner at Maagit
        • 18373 ☆ A M B ☆
        • 3,141 Posts
        Sounds great! laugh
          Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

          Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
          • 19604 ☆ A M B ☆
          • 179 Posts
          I like this!
            MINDEFFECTS – DESIGN for PRINT, WEB and MEDIA
            http://twitter.com/mindeffects · http://www.facebook.com/mindeffects · http://www.youtube.com/mindeffects/ · skype://mindeffects_oliver
            • 36924 ☆ A M B ☆
            • 298 Posts
            Smart (though I only read through half way!). I usually have to review and review Bob's notes on his site in achieving any front-end login functionality, with a lot of try-repeat and fail.
              • 42562
              • 1,145 Posts
              Methinks me be sad sad
              I love the old/current system - oh it is like Chess: lovely!
              ... just lovely and royal!
              But I guess, not everyone plays/enjoys Chess sad
                TinymceWrapper: Complete back/frontend content solution.
                Harden your MODX site by passwording your three main folders: core, manager, connectors and renaming your assets (thank me later!)
                5 ways to sniff / hack your own sites; even with renamed/hidden folders, burst them all up, to see how secure you are not.