Bug 873311

Summary: [RFE] Org level permission to manage users
Product: Red Hat Satellite Reporter: Jason Montleon <jmontleo>
Component: Content ManagementAssignee: Marek Hulan <mhulan>
Status: CLOSED ERRATA QA Contact: Tazim Kolhar <tkolhar>
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.0.0CC: bkearney, cwelton, howey.vernon, mhulan, mmccune, riehecky, sthirugn, tkolhar
Target Milestone: UnspecifiedKeywords: FutureFeature, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
URL: http://projects.theforeman.org/issues/5929
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-12 05:07:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jason Montleon 2012-11-05 14:34:11 UTC 
Description of problem:
In Red Hat IT we will have at least 5 Orgs, and possibly 6 or more. I do not want to have to manage users for every single Org, but giving a user permissions to create users means they can create users in ANY Org. I would like to be able to assign the role to a user that allows them to create users in their Org only. They can then decide what the new users are able to do within their Org up to and including creating new users themselves.

Version-Release number of selected component (if applicable):
System Engine 1.1 Beta

How reproducible:
Always

Steps to Reproduce:
1. Create a new user and give them full access to a single Org
2. Give them roles to create, manage, modify, and delete users
  
Actual results:
They can manage users in any Org, though because of https://bugzilla.redhat.com/show_bug.cgi?id=873302 they can't actually create users.

Expected results:
User management permissions should be on a per Org basis.

Additional info:
Comment 2 Jason Montleon 2012-11-05 15:13:27 UTC 
Thinking a little more about this and the fact that users are global and can have access to multiple Orgs, maybe the key is that someone without a specific permission within an Org (or global permission to do so) can not assign roles on behalf of that Org.
Comment 3 Bryan Kearney 2014-08-12 12:46:55 UTC 
Upstream bug assigned to mhulan
Comment 4 Bryan Kearney 2014-09-02 10:01:13 UTC 
Moving to POST since upstream bug http://projects.theforeman.org/issues/5929 has been closed
-------------
Marek Hulán
PR https://github.com/theforeman/foreman/pull/1479
-------------
Marek Hulán
Applied in changeset commit:952396005dadab63a81cb4763e0a3dab3c3f204f.
Comment 6 Marek Hulan 2014-10-13 07:37:25 UTC 
On which version did you test it? Also this sounds more like that context autoselection does not work when there's only one org, but BZ was about permissions scoping.
Comment 7 sthirugn@redhat.com 2014-10-14 14:30:40 UTC 
Version Tested:
Nightly Oct 10, 2014
* apr-util-ldap-1.3.9-3.el6_0.1.x86_64
* candlepin-0.9.32-1.el6.noarch
* candlepin-common-1.0.8-1.el6.noarch
* candlepin-selinux-0.9.32-1.el6.noarch
* candlepin-tomcat6-0.9.32-1.el6.noarch
* elasticsearch-0.90.10-7.el6.noarch
* foreman-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-compute-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-gce-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-libvirt-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-ovirt-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-postgresql-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-proxy-1.7.0-0.develop.201410081229git52f0bac.el6.noarch
* foreman-release-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* foreman-selinux-1.7.0-0.develop.201409301113git2f345de.el6.noarch
* foreman-vmware-1.7.0-0.develop.201410091913git35b6fb9.el6.noarch
* katello-2.1.0-1.201410091751gitc9c45c1.el6.noarch
* katello-certs-tools-2.0.1-1.el6.noarch
* katello-default-ca-1.0-1.noarch
* katello-installer-2.1.0-1.201410021645git304e036.el6.noarch
* katello-repos-2.1.1-1.el6.noarch
* katello-server-ca-1.0-1.noarch
* openldap-2.4.23-32.el6_4.1.x86_64
* pulp-docker-plugins-0.2.1-0.2.beta.el6.noarch
* pulp-katello-0.3-3.el6.noarch
* pulp-nodes-common-2.5.0-0.7.beta.el6.noarch
* pulp-nodes-parent-2.5.0-0.7.beta.el6.noarch
* pulp-puppet-plugins-2.5.0-0.7.beta.el6.noarch
* pulp-puppet-tools-2.5.0-0.7.beta.el6.noarch
* pulp-rpm-plugins-2.5.0-0.7.beta.el6.noarch
* pulp-selinux-2.5.0-0.7.beta.el6.noarch
* pulp-server-2.5.0-0.7.beta.el6.noarch
* python-ldap-2.3.10-1.el6.x86_64
* ruby193-rubygem-ldap_fluff-0.3.1-1.el6.noarch
* ruby193-rubygem-net-ldap-0.3.1-2.el6.noarch
* ruby193-rubygem-runcible-1.2.0-1.el6.noarch
Comment 8 Marek Hulan 2014-10-17 07:14:31 UTC 
So there's another permission that you must assign. Steps should be (notice 2a):

Steps for retest:
1. Create userrole - role1
2. Create a filter with Permissions create_users, destroy_users, edit_users, view_users. Also associate that filter to only one org - say org1
2a. Create a filter with Permissions view_organizations, assign_organizations, make it limited (uncheck Unlimited? checkbox) and specify "name = org1"
3. Create an user user1 and associate role1
4. Login with user1 and try to create a new user user2
5. User creation failed, no error thrown in UI.

Another issue is that for some reason we don't display errors. But that should be another BZ, although I think we have redmine issue for this.
Comment 11 sthirugn@redhat.com 2015-03-23 21:04:50 UTC 
Unassigning my name to focus on the feature testing
Comment 12 Tazim Kolhar 2015-03-25 10:44:10 UTC 
VERIFIED:

# rpm -qa | grep foreman
foreman-debug-1.7.2.13-1.el7sat.noarch
ruby193-rubygem-foreman_hooks-0.3.7-2.el7sat.noarch
rubygem-hammer_cli_foreman-0.1.4.6-1.el7sat.noarch
foreman-ovirt-1.7.2.13-1.el7sat.noarch
foreman-proxy-1.7.2.4-1.el7sat.noarch
dhcp201-150.englab.pnq.redhat.com-foreman-client-1.0-1.noarch
dhcp201-150.englab.pnq.redhat.com-foreman-proxy-1.0-2.noarch
rubygem-hammer_cli_foreman_discovery-0.0.1.3-1.el7sat.noarch
foreman-compute-1.7.2.13-1.el7sat.noarch
foreman-libvirt-1.7.2.13-1.el7sat.noarch
ruby193-rubygem-foreman_docker-1.2.0.6-1.el7sat.noarch
ruby193-rubygem-foreman-redhat_access-0.0.9-1.el7sat.noarch
foreman-selinux-1.7.2.8-1.el7sat.noarch
dhcp201-150.englab.pnq.redhat.com-foreman-proxy-client-1.0-1.noarch
foreman-discovery-image-2.1.0-9.el7sat.noarch
rubygem-hammer_cli_foreman_bootdisk-0.1.2.5-1.el7sat.noarch
foreman-vmware-1.7.2.13-1.el7sat.noarch
ruby193-rubygem-foreman-tasks-0.6.12.3-1.el7sat.noarch
ruby193-rubygem-foreman_gutterball-0.0.1.9-1.el7sat.noarch
ruby193-rubygem-foreman_bootdisk-4.0.2.9-1.el7sat.noarch
foreman-gce-1.7.2.13-1.el7sat.noarch
foreman-1.7.2.13-1.el7sat.noarch
ruby193-rubygem-foreman_discovery-2.0.0.8-1.el7sat.noarch
foreman-postgresql-1.7.2.13-1.el7sat.noarch
rubygem-hammer_cli_foreman_tasks-0.0.3.3-1.el7sat.noarch

able to create new user logged in as user1
Comment 13 Bryan Kearney 2015-08-11 13:31:56 UTC 
This bug is slated to be released with Satellite 6.1.
Comment 14 errata-xmlrpc 2015-08-12 05:07:03 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2015:1592