make ACLs easier or provide wizard

Quote from: splittingred at Jan 10, 2012, 09:44 PM

Thanks guys for the responses. A few things:

3. With regards to a wizard - it's really hard to develop a wizard without use cases to make the steps of a wizard. When we've asked for use cases before, silence followed. If we can get a good list of 5-10 different use cases, we can look into a wizard (either in an Extra or the core).

Shaun,

Not exactly use cases, but some things to think about:

Limiting user's actions in the Manager Context
Hiding Resources in the Manager
Hiding Elements in the Manager
Controlling Access to Resources in the Manager (IOW, not hidden, but limited actions)
Controlling Access to Elements in the Manager
Hiding Top Menu Items in the Manager
Hiding resources in the front end
Member Pages - User can only see one page, and (optionally) its children
Member Pages2 - User can only create, see, and edit one page, and (optionally) its children

I've worked on a Wizard for this in my head, but never had time to do anything concrete.

One key feature would be for the Wizard to issue a printable statement at the end explaining what it did and why. That would help people learn to go beyond the Wizard.

Another thing I learned in thinking about it and helping people with permission problems is that it will be critical at the beginning of the Wizard to guide the user in figuring out what they really want to do because many people don't really know at that point.

Also, I hope to have a couple of plugins out soon to add a default resource group and a default user group.

---------------------------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using . . . PLEASE!
MODx info for everyone: http://bobsguides.com/MODx.html

I wholeheartedly agree with a lot that's being said in this thread, but I cringe at the thought of introducing wizards to patch up the problems. Wizards can be useful additions, when they allow you to speed up a tedious and often used procedure, and/or when it gathers anumber of otherwise scattered settings in one place. In this case however, the wizard should mask the problems of an essentially - by it's mere complexity - flawed system. And I do feel that the current security system is just that, despite how much I am in love with MODX Revo (and I am) and respect it's makers (which I do). Fixing a broken system with a wizard is like mending a bad relationship with a baby: It will blow up in your face eventually, and the bang will be so much the bigger.

Just like Pleth, even when I feel I set the system up right, problems may occur. And fixing problems, may create new ones. Which means that even when things (seem to go) right, I never fully trust the system and I'm always anxious about new security requests from my clients. In fact, seeing myself struggle, it makes me suspicious of the reliabilty of snippets. And at times I even worry if the MODX team itself may sometimes get it wrong. These are all things that no wizard can fix, but do make me wonder whether MODX is the right CMS. And I'm a fan!

In an attempt to once and for all get a grip on the MODX Revo security system, I decided to put it to the test in a real-life website I was about to make. It included 4 contexts (nl, en, de and fr) and 3 user groups (admins, editors and guest editors), each containing 2 or 3 roles. I used 4 Resource Groups (admins, editors, guest editors and members). After a short while I stoppped setting up the system, as I realized what ncrossland reported about earlier: The fine grainyness of the system - that should allow for large and complex setups - demands such a large number of settings to be made, which consumes so much time to do and results in such an unwieldy amount of settings to maintain, that it basically kills the usefulness of the security system.

So much for my concerns, what about solutions? It's pretty hard to come up with solutions that are all in tune and don't break the current system (too much), as I'm sure you'll all agree, but here's a number of suggestions I feel pretty confident about:

1. Make the default Administrator a Super Administrator
It seems we all agree about the fact that MODX needs a Super Administrator (or Super Administrators Group) that always has access to everything and everyone. I hope the solution proposed by splittingred will effectively do just that.

2. Add "Any Context" as a selectable option when adding rules
Instead of making a seperate rule for every Context, it would be very useful (saving time and a lot of clutter) to make rules applying to all Contexts. I believe this has been suggested in a previous thread and rejected (by opengeek?) for technical reasons, but I still believe it's essential to add this as an option. (If I'm correct it couldn't be done because the Manager is also a Context. Maybe if you'd give Contexts ID's, starting with 0 for the Manager, 'All Contexts' could be defined as ID != 0. Just thinking out loud.)

3. Allow the choice for a Simple or an Advanced System
This has been suggested by a number of people and rejected by splittingred, but I think it can be achieved without disrupting MODX too much. It could be activated by using 1 or 3 System Settings, or by including check boxes on the relevant pages and tabs. Simple Mode could be done in the following way:

3a. Hide any reference to Roles. When Users are added to a User Group, automatically assume they are Super Users.

3b. Hide any reference to Contexts. When an Access Policy is added, automatically assume it's set for all Contexts.

3c. Link Resource Groups to User Groups. When adding a User Group, automatically add a Resource Group. To prevent disasters, disallow creating, updating or removing Resource Groups in the Resource Groups page while this setting is active.

4. Give Templates a default Resource Groups setting
Why not include a default Resource Groups setting as a setting for Templates, including the option to inherit these settings from the parent Resource. That would give way more control than a single System Setting.

This is what I have come up with so far, but I'm still working on other ideas. Whatever I'm happy with will find it's way to this thread in the future.

I've thought about this a fair amount, and don't have any universal solution, but in the interest of fostering discussion, here are some ideas I've had:

1. In the UI, make a clearer separation between the process of controlling what actions users can perform and the process of hiding and showing resources and elements. Having these intermingled in the UI quadruples the complexity from a cognitive standpoint.

2. Make the admin Super User invincible. I don't think this would break any reasonable existing install. I don't think many sites intentionally restrict the rights of the Super User. The obvious question is whether to make *any* admin Super User invincible. That would create some issues about users with different roles in different groups and might break some existing sites, but my gut feeling is that it's a good idea, since you don't *have* to create extra admin Super Users if you don't want to.

3. In the UI, tie what actions users can perform in the Manager directly to roles, like in Evo. This makes intuitive sense to people, and the concept of authority levels really doesn't, because in the present system, whether a user can perform a specific action depends on a very complex interaction between roles, authority levels, user groups, resource groups, contexts, and potentially a whole raft of ACL entries and Form Customization rules.

Users could have one role for the manager in general and one role in each other user group they belong to. I think this is equivalent to the system we have now, but it would be much easier to understand if the permissions were tied directly to the role. We might lose the ability to control actions by context, but I think it would be worth the price, since few people understand how that works anyway.

As I envision it, this would mean doing away with resource and element policies (and their permissions) so there would only be one kind of policy -- that would simplify things immensely. The user's ability to perform actions on specific resources and elements would depend on their role in the group that had access to those objects.

4. Make all rules that pertain to contexts other than 'mgr', apply only in the front end. If there were a "hide_contexts_in_manager" permission with a list of contexts the user shouldn't see in the Manager, it would hide those contexts, which would be visible by default. The fact that a user needs an explicit Context Access ACL entry to see any resources in the 'web' context in the Manager is a huge stumbling block for many users, especially after we tell them that the 'web' context is the front end.

5. Hiding Resources - I would keep this largely as is (as it was in Evo). If resources groups are tied to user groups, the resources are protected from access by members of other groups. We wouldn't lose the ability to control what users can do with particular sets of resources, because users could have different roles in different groups.

6. Member pages - There has to be an easy way for users to do this. Creating a user group for each user, a resource group for each resource, and a separate ACL entry for each pair just isn't workable. I think the best way to do this without breaking anything is to enforce the tree_root_id user setting in all permission checks.

It might make sense to have a separate tree_root_id setting for the front end and the Manager. It might also make sense to put this setting in the user form, make it a right-click option in the tree, and/or provide a way to set it by clicking in the tree as with setting the parent.

----------------------------------------------------------------------------------------------------------------

The current system is immensely granular and powerful, but apparently unusable for an awful lot of users. Even when they understand it (and many don't), they don't have a lot of confidence in their abilities. It was our hope that with good enough documentation, people would come to understand the system, but I don't think the documentation can be improved much further and it clearly isn't working.

I don't have trouble with the permission system, though I often accomplish what I want with custom snippets and augment the system with custom plugins. That's not an option for the vast majority of users and potential users, though. Eventually, all CMSs have to face the issue of usability by non-technical users. Even when a web site is built by a tech-savvy user, it often is maintained by a secretary and the permissions system is a significant part of that maintenance when new users and new content are added. IMO, we're definitely going to have to do something to make the system easier to use and understand.


---------------------------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using . . . PLEASE!
MODx info for everyone: http://bobsguides.com/MODx.html

Just about compatibility:

We had big changes even in 2.0.x releases where sites could have been broken after upgrade. So I don't see a reason to introduce within 2.3 release.
But I think this is the major point we need for 2.3 – not later.

@BobRay

1. In the UI, make a clearer separation between the process of controlling what actions users can perform and the process of hiding and showing resources and elements.

I agree. The question is how to do this in such a way that the system becomes clearer and not more cluttered. I'm still breaking my head over this one.

2. Make the admin Super User invincible.

I think we all agree on this one.

3. In the UI, tie what actions users can perform in the Manager directly to roles, like in Evo.

I can't help wondering if Authority Levels and Permission Policies could be turned into a benefit if you'd restructure them. I agree they're a burden right now, but maybe they just need a different implementation.

4. Make all rules that pertain to contexts other than 'mgr', apply only in the front end.

I wholeheartedly agree on this one. To some extend I think it ties in with your first and third point. One of the main issues I have with the current security system, is the fact that the Manager is treated as an equal to all other Contexts. That may be logical and perhaps even desirable from a coding point of view, but for any non-developer it's confusing as hell. On top of that it clutters the interface, making it far more complex than it needs to be.

5. Hiding Resources. If resources groups are tied to user groups, the resources are protected from access by members of other groups.

That's basically the point I was trying to make with 3c. Differentiating between Resource Groups and User Groups may serve a purpose, but does it outweigh the added complexity? I think we can live without.

6. Member pages. Creating a user group for each user, a resource group for each resource, and a separate ACL entry for each pair just isn't workable.

I'm not quite sure I understand this one. Are you aiming at pages only accessible by a single member?

Eventually, all CMSs have to face the issue of usability by non-technical users. Even when a web site is built by a tech-savvy user, it often is maintained by a secretary […].

Spot on! For anyone making commercial websites, it's essential that the client can handle the security system without the need for a technical background. In spite of any other qualities, if this isn't true, the CMS is not an option.

I ran into more problems today with ACL. I only wnat one simple thing: a user who can only access one resource. My try to do this blocked Admins from access media-sources, broke ressource-tree, I had to set values in my database to get my ressources back!!!

This is when I think as a MODX partner that I should consider changing the CMS. I always thought I can build big sites with MODX which is entirely true as you don't have to fight with ACL.

So I concluded to only use MODX for sites where I don't need any permission system at all. All other will now get another CMS until MODX fixes that entirely.

And with that I agree that a wizard is not the right way. A wizard is also based on the same concept but if the concept at all is broken a wizard won't change anything.
So let's focus what might be a solution:

Why not changing the whole system by saying:

- create a user
- can be admin / user
- if admin > access all
- if user can't view / edit anything at all by default
- then I can give the user access to specific resource where he can do anything

In what cases won't that work?
Or do both systems. But sorry, even Wordpress, Drupal and TYPO3 had cost me less time to develop the one site. And you know what this means…

@benmarte
THANK YOU VERY MUCH for your tutorial:

http://bmv-interactive.com/home/modx-acl-tutorial.html

I totally agree when you say

every time you create a new resource and you don't want the Editor User Group to have access to it you will have to go to the Access Group tab and select what group the new resource is part of

...

You can also use the Resource Group method by going to Security > Resource Group and drag and drop the new resource to the Admin Resource Group (yes, I know this is very tedious and a PITA) I really hope there is some setting that can be changed so this can be avoided if not then it's just something we're going to have to deal with until MODX comes up with a revamped ACL system.

I've got a big problem in a site where I have a huge number of resources that have been created without assigning any Resource Group. I can't drag&drop one by one,... well, actually I can't drag even a single item because the number of items is so high that I need to scroll the page to get them and the Resource Group tree on the left side disappear outside the top edge of the frame. (Revo 2.1.2)

Is there any batch process to put all of them inside the right Resource Group?

MODx is geat and I love it but I'm really surprised that access management is so user-un-friendly. For example I would expect that a resource (if not explicitly specified by the user) inherit permissions (User Group membership) from its parent folder/container, but probably I miss the reason why.

My excuses for my bad english but I hope you get the point.

Any suggestions?

Thanks.

@anto-fle

I have also had trouble with this - please add your vote to feature request http://bugs.modx.com/issues/6622

Quote from: chunkyRice at Jan 19, 2012, 12:03 AM

In an attempt to once and for all get a grip on the MODX Revo security system, I decided to put it to the test in a real-life website I was about to make. It included 4 contexts (nl, en, de and fr) and 3 user groups (admins, editors and guest editors), each containing 2 or 3 roles. I used 4 Resource Groups (admins, editors, guest editors and members). After a short while I stoppped setting up the system, as I realized what ncrossland reported about earlier: The fine grainyness of the system - that should allow for large and complex setups - demands such a large number of settings to be made, which consumes so much time to do and results in such an unwieldy amount of settings to maintain, that it basically kills the usefulness of the security system.

In a site I recently had to set up, there were approx 10 content areas (resource groups). We neded to control which users can access which areas. Should be simple - used to be fairly straightforward in Evo.

In Revi, as well as setting up the resource groups, a custom editor policy template (choosing which of the individual 172 permissions we wanted to assign to these users), the access policy itself, we then had to set up 10 user groups. So far, not unreasonable. This is where the pain starts.

For each user group, we have to assign the relevant resource group, both for mgr and web. That's 20 settings to add. We also have to give them explicit context permissions for mgr and web - that's another 20 settings to add.

But then, we find that when a user is logged in, they can't access the REST of the public website (the bits that are public, but they can't edit) because they don't have explicit permission to do so. So we then have to add web permissions (but not mgr) for each user group. That's another 90 sets of permissions to add. It feels like there should be some shortcut here - maybe with context permissions to override this - but we couldn't get it to work. If anyone can shed some light, it would be most welcome.

So all in all, we've had to manually set up 130 individual permission items to set up our 10 content areas. This is literally an exponential increase in manual effort for every new resource group we add.

If we were to add a new resource group, we'd have to manually add permissions to every other user group for them to be able to view it in the front end. The client can't do this. Oh, and don't forget to add it to the SysAdmin's user group too, or all those resources will disappear from the interface entirely, with no way of knowing what's happened to them until you remember.

We've had to provide specific instructions on how they add users - instead of a tick box of resource groups (as in Evo) they have to add each resource group one at a time to a new user (remembering my instructions about which Role they need to have).

And good luck if you've got lots of existing content to put into resource groups - you have to be prepared to manually open every document on your site, or drag each one individually through the resource group management screen.

Having read and thought further, I think a wizard would be a layer of fudge on a system which is fundamentally over complicated for what it needs to be to achieve 99% of developers' and users needs. It would have to have a wizard not just to create a new setup, but maintain existing ones. Surely a better solution it to fix the problem, not just fudge it.

These are, as I see it, the main problems. I'll hopefully follow up with a more constructive post on solutions.

Just to chime in, we are absolutely listening and agree there is a serious UX problem. The underlying power of the attribute based access controls is tremendous and admittedly overkill for many use cases. We look forward to seeing it be a hell of a lot simpler and less tedious for these type of needs.

That being said, we sincerely appreciate the suggestions and sharing of frustration. Please keep the ideas flowing—in fact we'd love to see some mockups or wireframes of ideas even if it's just to fix a small part of the problem.