Created redmine issue http://projects.theforeman.org/issues/25448 from this bug

Ori, I think this is something you were answering few times, mind to link related BZs?

The wrong assumption in comment 0 is "3. Org A has a user `jack` who can edit class parameters for Org A. `jack` is not a member of Org B". The problem is, class parameters are never scoped to organization, so use can't be limited to only edit parameters in Org A. The user either can edit parameters or can not. This is a limited multitenancy for configuration management. The implementation is very complex and I think we closed as WONTFIX in other BZs. But I'd defer to Ori, I think there were some alternative solutions to this problem.

This BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1329992 also contains a link to another BZ, both were closed as won't fix.
 
It is possible to change permissions and block access to the puppet classes themselves because they are not connected to organization/location.
Instead the parameters can be edited from the host/hostgroup that are scoped by organization.

Using the role of Org Admin, each admin would only be able to edit and see overrides on the host/hostgroup that belong to the org but won't have access to the puppet classes.

The puppet classes themselves will only be edited by a super admin.
The super admin will override the needed parameters and then they can be set per host/hostgroup without the option to see any other overrides outside the org.
This can be scripted through the API for specific or all parameters of a new puppet class addition.

Puppet classes, and their respective parameters, are by design shared between all organizations and do not belong to a specific one. There is no concept of organization-specific class parameters - parameters can have matchers for a specific organization, allowing complicated overriding rules for values, but these do not make the parameter "belong" to a specific organization. 

Any user granted permission to edit class parameters will be able to affect multiple organizations. If a user should not have permission to edit parameters, they should not be granted the "edit_external_parameters" permission, whether directly or via a pre-defined role, similar to any other permission that may permit them to affect any other resource that is shared between organizations.

Closing as NOTABUG.

Hello,

This behavior is not different from that of many other resources that are shared between organizations.  Some resources may be scoped to certain organizations, but they may also be shared between organizations. Other resources, such as puppet classes and their parameters, are always shared between all organizations. 
Due to this, similar issues can occur if, for example, a user permitted to edit operating systems edits an operating system (which also does not have an organization scope), or a user permitted to edit domains edits a domain (which may shared between multiple organizations). 
In other words - changes to any such shared resource can impact multiple organizations and should be done with care.
Organizations in Satellite are used as a method for grouping certain resources together to ease infrastructure and asset management, not of ensuring complete isolation between all resources, since in many cases it is actually very useful to share some resources between organizations. If you need to ensure complete isolation between two organizations for all resources, you might want to consider running a separate Satellite instance for each organization.

To resolve the specific example, users can use more specific matchers for smart class parameters to ensure they do not affect other organizations. 
In the example given, the user in org A should do the following, instead of changing the default value for the parameters:
For ensure parameter, add a matcher for "organization=Org A" with a value of "stopped".
For enable parameter, add a matcher for "organization=Org A" with a value of "false".
and similarly for the second user and so forth. 
Matchers can even be combined if needed for more complex logic, e.g. "organization,hostgroup=Org A,DBs".

If needed, regular satellite users can be prevented from modifying these parameters directly by not granting them the "edit_external_parameters" permission and only allowing the satellite administrators, who have visibility to all organizations, to make such changes.