MODX Staff
Not at all, Contexts are the distinction for Users and Resources as you can apply Policies to specific Contexts without affecting permissions in other Contexts. And you login to specific Contexts as well. Each user has a list of ACLs cached in their session and these are stored by ACL type and by Context.
1. The distinction between the front end and back end is truly gone, not just for users, but for resources as well -- If you have the authority to see see a resource in the back end, you can see it in the front end and if you don’t, you can’t see it in either place.
Correct, though you can certainly create additional Permissions to use in those Policies. However, it would be smarter to create and apply custom Permissions via custom Policies isolated from the Policies you create from the built-in ones designed for Contexts and Resources. And for a more complete understanding, load, save, and remove are permissions built-in for use with any modAccessible object (of which modContext and modResource are) which affects the ability to load, save, or remove instances of that object.
2. Context Access ACLs have policies based on the standard Administrator policy, Resource Group Access ACLs have policies based on the standard Resource policy.
Well, it restricts access to Resources in the ResourceGroup to Users who are members of the UserGroup with enough Authority in a specific Context; this will be of major importance in designing security models for multi-domain installations with each domain represented by a Context.
3. User Group Resource Group Access ACLs generally need access only to the Mgr context unless you want to restrict access to that Resource Group in the front end as well.
If you protect a Context other than mgr using the default Context Policy, you are giving those Users permission to perform any content management actions on any data they have access to from that Context (think front-end editing), and you are preventing other Users from being able to access that Context at all unless you provide an anonymous Context ACL to a Policy that has the very important "load" Permission. This allows any User to be able to load the requested Context and thus access Resources contained in it. If you do not link a Context to a Policy, it is the same as providing this anonymous "load" permission to everyone for that Context.
4. User Group Context Access ACLs generally need access to both Mgr and Web contexts if they’re doing more than just listing and viewing. (not so sure about this one)
Assuming they have access to the Context from which you are requesting that Resource, yes. Further, it is available to everyone unless a Resource Group ACL exists in the Context you are accessing it from.
5. Any resource not in a Resource Group is available to everyone.
Not at all, no Resources in a Resource Group is protected unless there is at least one ACL which applies a Policy to that Resource Group in the Context you are accessing the Resource from.
6. Any resource in a Resource Group (whether or not it’s tied to a User Group) is only available to those who are explicitly given access to it somewhere (including the super admin).
If you want to protect all Resources in the mgr by default and achieve a security model that was not really possible in Evo, then yes, that is how you would go about doing it.
7. Putting all resources in a single resource group and giving the main admin access to that Resource Group with the standard resource policy in the Mgr context means the admin can see and edit everything, no matter what else you do, and won’t affect viewability in the front end. (is this an OK practice?)
Resource Group access has nothing to do with "web" Context Access, so I’m confused by this statement.
8. Giving a User Group access to the mgr context in a Context Access ACL permits them to perform the actions in the specified policy (and inherited policies) in the manager, but doesn’t give them access or authority to see or edit any resources that are in Resource Groups. For that, they need "web" Context Access *and* they need to be granted access to the Resource Group in a Resource Access ACL (with a context of mgr).
More simply, Context ACL’s affect permissions to perform content management actions and permissions to load, save, and remove Contexts. Resource Group ACL’s affect various Resource specific permissions to Resources by User Group and Context. I’m still confused by how you are describing this I think.
9. Giving a User Group access to the web context in a Context Acess ACL permits them to perform actions in the specified policy (and inherited policies) on the resources in that context that are not in Resource Groups. They also need to be granted access in a Resource Group Access ACL (usually with a mge context) to perform actions on resources in Resource Groups.
Correct, permissions are 100% additive.
10. When more than one permission rule applies in a situation, the most permissive rules.
Correct.
11. If a user has access to a resource via a User Group-Resource Group connection, he or she gets access to that resource regardless of the resource’s position in other Resource Groups the user doesn’t have access to.
Quote from: BobRay at Dec 29, 2009, 10:32 PMNot at all, Contexts are the distinction for Users and Resources as you can apply Policies to specific Contexts without affecting permissions in other Contexts. And you login to specific Contexts as well. Each user has a list of ACLs cached in their session and these are stored by ACL type and by Context.
1. The distinction between the front end and back end is truly gone, not just for users, but for resources as well -- If you have the authority to see see a resource in the back end, you can see it in the front end and if you don’t, you can’t see it in either place.
4. User Group Context Access ACLs generally need access to both Mgr and Web contexts if they’re doing more than just listing and viewing. (not so sure about this one)
If you protect a Context other than mgr using the default Context Policy, you are giving those Users permission to perform any content management actions on any data they have access to from that Context (think front-end editing), and you are preventing other Users from being able to access that Context at all unless you provide an anonymous Context ACL to a Policy that has the very important "load" Permission. This allows any User to be able to load the requested Context and thus access Resources contained in it. If you do not link a Context to a Policy, it is the same as providing this anonymous "load" permission to everyone for that Context.
MODX Staff
I don’t see any conflict between our two statements.You said the distinction between front-end and back-end was gone, and I simply clarified that the distinction between front-end and back-end is the responsibility of Contexts now, and that mgr is still the "back-end" and all other Contexts are basically "front-end". The distinction still exists, it’s just implemented differently, and we can now blur the lines since content management processors can be called from any Context.
Still confused here. Taking away web context access from a user group makes all the resources in that context disappear from the tree memeber of that group in my setup. Adding it back doesn’t restrict access in the front end.If you do not assign any Context Policy to any User Group to the web Context specifically, all would have access to the Context in the mgr, but there is one assigned to the Administrator group by default (if you removed it, all User Groups with access to mgr would see the web context). Once one Policy is assigned to the web Context (via Context ALCs), only those with explicit permission can even "load" that Context. And it doesn’t restrict access in the front-end because all anonymous users automatically get load permission on the Context being initialized by a MODx request (other than mgr). Once again, the reason for my description was to make sure you understand that any User Group which is assigned the default Context Policy on web (or any other Context) will have permission to perform all content management activities from components executed in that Context. This could be anything from clearing the cache to deleting a Resource to changing the name of an Element.
You said the distinction between front-end and back-end was gone, and I simply clarified that the distinction between front-end and back-end is the responsibility of Contexts now, and that mgr is still the "back-end" and all other Contexts are basically "front-end".
MODX Staff
Please point me to this example, cause I’m lost on what Resource Group ACLs assigned in the web context had dramatic effects on the back-end? I described the behavior related to the issue when assigning Context ACLs, since the Contexts themselves are the targets of the assigned Policies rather than a "within a specific Context" type of access control mechanism. Again Context ACLs are a little different in that they both control your ability to load (or save or remove) the data from the context table (from any Context), as well as control what content management permissions you have when requesting pages via that Context.
Quote from: OpenGeek at Dec 30, 2009, 05:41 PM
You said the distinction between front-end and back-end was gone, and I simply clarified that the distinction between front-end and back-end is the responsibility of Contexts now, and that mgr is still the "back-end" and all other Contexts are basically "front-end".
If this were true, it would make things infinitely simpler, but it just isn’t, in my experience. Unlike Evolution, the use of the web context in ACLs quite often has dramatic effects in the *Back End* (there’s an example of it in my last message). That’s one of the primary things that makes this difficult for me.
Quote from: BobRay at Dec 30, 2009, 06:14 PMPlease point me to this example, cause I’m lost on what Resource Group ACLs assigned in the web context had dramatic effects on the back-end?
Quote from: OpenGeek at Dec 30, 2009, 05:41 PM
You said the distinction between front-end and back-end was gone, and I simply clarified that the distinction between front-end and back-end is the responsibility of Contexts now, and that mgr is still the "back-end" and all other Contexts are basically "front-end".
If this were true, it would make things infinitely simpler, but it just isn’t, in my experience. Unlike Evolution, the use of the web context in ACLs quite often has dramatic effects in the *Back End* (there’s an example of it in my last message). That’s one of the primary things that makes this difficult for me.
MODX Staff
In Revo this is basically the same except a User Group + Context defines access to the "front-end"; instead of having Web Access Permissions and Mgr Access Permissions, you can now have Access Permissions to any number of different Contexts, including, but not limited to web and mgr.
I didn’t say Resource Group ACLs and I was thinking of Context Access ACLs when I wrote it. In Evo,
web groups == the web == the front end.
Context Access, which defines access to a specific Context, and replaces the Evo concept of Role Permissions by giving the ability to define Permissions for content management activity per Context. IOW if QuickManager or QuickEditor existed for Revo and was being used in the web, or any other Context besides mgr, it could be governed by a different set of Permissions, aka Policy, than access to the mgr. Access to Contexts is a pretty simple concept here; consider a multi-domain setup with one manager. You need to be able to give Content Editors responsible for a specific domain the ability to manage everything related to their own "front-end" Context, but without being able to see or modify data in Contexts that other Content Editors may be responsible for.
In Revo, this is the case for Resource Group ACLs but, as you explain, is not the case for Context Access ACLs. I think I understand it, but I don’t think anyone is going to get it intuitively or come to it by experimentation. Nor will they easily grasp the side effects of granting web context access by default to administrators, IMO.
Context ACLs do not affect your ability to see/modify Resource directly. They affect a) your ability to load/see a Context at all, from anywhere, and b) your content management Permissions that used to be handled by Role Permissions in Evo. It simply lets you define access permissions to/within Contexts. How is this not intuitive?
When you say, "Context ACLs simply have targets of, well, Contexts" it’s somewhat misleading, IMO, because Context ACLs, in practice, affect the ability to see and modify resources; and Resource Groups can effect which ones (no?) even though they’re not explicitly tied to Context Access ACLs in any way.
This is called a Context, period. It does not mean anything different in Resource Group ACLs; it still refers to the same data objects. Resource Group ACLs simply join a Resource Group with a User Group within a specific Context. Context ACLs simply join a Context with a User Group; there’s no "within a specific Context" ’cause these are Contexts, and that wouldn’t make any sense, now would it?
1) The confusing (arguably ambiguous) use of the term "web," which, to some extent, means one thing in Resource ACLs and another in Context ACLs;
How can protecting a Context from access by someone not affect the Tree, since the root elements of the Tree are Contexts? This seems elementary to me, and I don’t understand why this is confusing. If you protect domain abc to user group abc, then only members of abc can see the abc context.
2) The fact that resources come and go from the Tree when you change Context Access ACLs and it’s hard to guess why, especially when you have three or four overlapping Resource Groups and users that exist in more than one User Group.
I’ve described the only Rules many times and in many ways, and my inability to make anyone grok this with the words I’ve used already is mind-boggling. This is an established concept of security, joining a target, a principal, and a policy to establish access to the main class in the software (since Context is the first thing that has to be initialized to execute a MODx request), and joining a target, a principal, and a policy within a limited context (since Resource Group + Context now replaces the duality of Web vs. Manager Access Permissions to Resource Groups).
The behavior of any security system is describable by a set of rules (if not, something is really wrong with the system). On the Bob’s Guides Permission page, I have a set of 7 rules that I believe completely describe (and define) the behavior of the Evo security system.
ABAC security systems are already established as a design. We’re trying to describe how MODx implements this design in a way that makes sense to people who don’t understand the established concepts of ABAC.
What I was trying to do above was create the same thing for Revolution permissions. I consider it the best form of documentation for this kind of system (and would have thought it would be a prerequisite for designing it).
I thought that’s what we were trying to do here, but all I’ve seen is very specific scenarios instead of generic descriptions of how the system works. I can’t describe the full-scope of this security system’s capabilities and detail a single scenario of usage at the same time. IMO, we need to spend time creating sample site packages that include sample robust security models to achieve a certain goal; examples are much easier to learn from in this case because the potential for implementation is basically limitless and entirely customizable/extensible for specific requirements.
You say my explanation is unnecessarily complicated (and I believe you). Give me a simpler, yet complete, set of rules and I will be one happy camper.
Quote from: BobRay at Dec 30, 2009, 09:03 PMContext ACLs do not affect your ability to see/modify Resource directly. They affect a) your ability to load/see a Context at all, from anywhere, and b) your content management Permissions that used to be handled by Role Permissions in Evo. It simply lets you define access permissions to/within Contexts. How is this not intuitive?
When you say, "Context ACLs simply have targets of, well, Contexts" it’s somewhat misleading, IMO, because Context ACLs, in practice, affect the ability to see and modify resources; and Resource Groups can effect which ones (no?) even though they’re not explicitly tied to Context Access ACLs in any way.
Quote from: BobRay at Dec 30, 2009, 09:03 PMI thought that’s what we were trying to do here, but all I’ve seen is very specific scenarios instead of generic descriptions of how the system works.
You say my explanation is unnecessarily complicated (and I believe you). Give me a simpler, yet complete, set of rules and I will be one happy camper.
Agreed, but I’ve never seen a numbered, full set of them and I still think it would be extremely useful (assuming that it’s not in set theory notation).
I’ve described the only Rules many times and in many ways.
☆ A M B ☆