Bug 1467364 - Provisions via Users in multiple groups in tenants in SSUI result in VMs being provisioned to wrong group/tenant
Provisions via Users in multiple groups in tenants in SSUI result in VMs bein...
Status: POST
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: API (Show other bugs)
Unspecified Unspecified
high Severity high
: GA
: 6.0.0
Assigned To: Gregg Tanzillo
Dave Johnson
: TestOnly
: 1473782 1473783 (view as bug list)
Depends On:
Blocks: 1481859 1513191 1480007
  Show dependency treegraph
Reported: 2017-07-03 10:19 EDT by Dustin Scott
Modified: 2017-11-15 15:52 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Consequence: Fix: Result: We might have to change the documentation to indicate that instead of using $evm.root['user'].current_group we should be using $evm.root['miq_group'] to get the requesters current group
Story Points: ---
Clone Of:
: 1480007 1481859 1513191 (view as bug list)
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: CFME Core

Attachments (Terms of Use)
Wrong group (111.06 KB, image/png)
2017-10-31 15:17 EDT, Shveta
no flags Details

  None (edit)
Description Dustin Scott 2017-07-03 10:19:11 EDT
Description of problem:

When provisioning virtual machines via the self-service UI, when a user is a member of multiple groups within a nested tenant structure, the VM and Request information does not necessarily belong to the tenant/group in which the user requested the provision from.  This holds true when attempting to switch groups (upper right hand corner).  It seems that switching tenants/groups in SSUI has no effect on which tenant/group is doing the provisioning, rather the group that is listed in Configuration > Access Control > Users > Group seems to control this.

Version-Release number of selected component (if applicable):

How reproducible:

Intermittent.  Theoretically, the correct group could be selected (e.g. user is a member of 5 groups.  There is a 1 in 5 chance that the correct group is selected by CFME).

Steps to Reproduce:
1. Configure Authentication on an appliance with the UI/Web Services role
2. Configure three (3) groups in the Authentication source.  The more groups which are configured will make the problem more apparent.
3. Add a single user to all above configured groups in the authentication source.
4. Create the following tenants in CloudForms: 
    a) Child Tenant 1 (Child of the root tenant)
    b) Child Tenant 2 (Child of Child Tenant 1)
5. Configure the above created groups in the CloudForms UI with a role that is eligible to provision service catalog items as follows:
    a) Group1 - root tenant
    b) Group2 - Child Tenant 1
    c) Group3 - Child Tenant 2
6. Create a catalog item (our testing used RHV as the provider) in the root tenant.
7. Login as the configured user, and for each configured group, execute a provision from the Admin UI and observe that the user can switch groups and provision items, without issues in each of those groups.
8. Clear the web browser cache, and re-open the web browser.  Ensure only one web browser window is open.  This ensures that we aren't running into issues with multiple open browsers.
9. Login as the configured user, and for each configured group, execute a provision from the Self-Service UI and observe that the provisioned items disappear from the view of the user.  The provision is not available to be seen in Request, or in My Services.  Switching groups/tenants will allow other users to see the provisions.
10. In this instance, remember that there is a 1 in 3 chance that the provision ends up in the correct tenant.  Rinse and repeat as necessary.

Actual results:

The provision executes successfully, but the request does not belong to the correct tenant/group and disappears from the per-view of the logged in user.  Switching groups allows the provision to be seen (the group which can see the provision seems to be unpredictable).

Expected results:

When executing a provision with a user who belongs to multiple groups in a tenanted structure, the provision stays with that tenant/group.  The provision request/service can be seen by the user in Requests and My Services.

Additional info:
Comment 2 Chris Kacerguis 2017-07-05 07:54:08 EDT
Gregg - could you take a look here, we pass very minimal user info (if any?) when provisioning...so, I'm wondering if this is API related?  Could you please take a look?  Feel free to kick it back to us if I'm wrong. :)
Comment 6 Chris Kacerguis 2017-07-25 10:25:38 EDT
Hi Lucy,

So, this is by design, the SUI and the Ops UI use different auth methods (sui uses a token) so we are not making an call to change the DB, so you shouldn't see anything.

Hope that helps.  

Comment 7 Lucy Fu 2017-07-27 14:27:16 EDT
*** Bug 1473782 has been marked as a duplicate of this bug. ***
Comment 11 Lucy Fu 2017-08-01 13:07:13 EDT
*** Bug 1473783 has been marked as a duplicate of this bug. ***
Comment 13 CFME Bot 2017-08-02 17:11:49 EDT
New commit detected on ManageIQ/manageiq/master:

commit 97b099d4bafb51a4343d1aa2273924ec571ea33a
Author:     Lucy Fu <lufu@redhat.com>
AuthorDate: Thu Jul 27 17:05:38 2017 -0400
Commit:     Lucy Fu <lufu@redhat.com>
CommitDate: Wed Aug 2 14:52:01 2017 -0400

    Set user's group to the requester group.
    User's current group might have changed before the provision finishes.
    So the user's current group from DB may be different from the user's group when the request is made.
    Need to set the user's group back to requester group the user is in when the provision is submitted.
    Therefore the provisioned instances may belong to the right user/group/tenant.

 app/models/mixins/miq_request_mixin.rb |  4 +++-
 spec/models/miq_request_spec.rb        | 20 ++++++++++++++++++++
 2 files changed, 23 insertions(+), 1 deletion(-)
Comment 15 CFME Bot 2017-08-09 17:04:04 EDT
New commit detected on ManageIQ/manageiq-automation_engine/master:

commit 660b111b6bcd0546ce00fc0e99e9767a9a2a83c8
Author:     Lucy Fu <lufu@redhat.com>
AuthorDate: Thu Jul 27 17:46:38 2017 -0400
Commit:     Lucy Fu <lufu@redhat.com>
CommitDate: Wed Aug 9 16:45:30 2017 -0400

    Need to pass the user's group in to automate when the provision starts.
    User's current group might have changed before the provision finishes.
    So the user's current group from DB may be different from the user's group when the request is sent into automate.

 lib/miq_automation_engine/engine/miq_ae_engine.rb       |  6 ++++--
 .../engine/miq_ae_engine/miq_ae_object.rb               |  2 +-
 spec/miq_ae_engine_spec.rb                              | 17 ++++++++++++++++-
 3 files changed, 21 insertions(+), 4 deletions(-)
Comment 16 CFME Bot 2017-08-09 17:06:44 EDT
New commit detected on ManageIQ/manageiq/master:

commit 46c7340d47815787fad2f07a5238d7b64b08a0df
Author:     Lucy Fu <lufu@redhat.com>
AuthorDate: Tue Aug 8 08:51:42 2017 -0400
Commit:     Lucy Fu <lufu@redhat.com>
CommitDate: Tue Aug 8 08:52:03 2017 -0400

    miq_group_id is required by automate.
    A user may belong to multiple groups.
    miq_group_id became required via https://github.com/ManageIQ/manageiq-automation_engine/pull/61.

 app/models/automation_task.rb       |  2 ++
 spec/models/automation_task_spec.rb | 15 ++++++++++-----
 2 files changed, 12 insertions(+), 5 deletions(-)
Comment 20 Matt Pusateri 2017-09-18 09:51:21 EDT
What type of authentication are you configuring LDAP?  Via MIQLDAP or External Auth? and or What Authentication provider(AD, OpenLDAP, FreeIPA)?
Comment 21 Shveta 2017-10-31 15:17 EDT
Created attachment 1346083 [details]
Wrong group

I have setup LDAP authentication on an appliance .
test-user1 belongs to group1 and group2 (both have permission to order services).
When ordered service as test-user1/redhat , Group displayed on service is "EvmGroup-super_administrator " in SUI. It should show "group2".

When ordered from OPS UI , correct group is shown .

Appliance : 
Service name = group.
Comment 26 Allen W 2017-11-02 09:18:16 EDT
Verified the group switching issue, gonna work with API team to figure out whats going on.
Comment 27 Allen W 2017-11-02 13:13:22 EDT
Ok ends up theres rbac magic at play here that is throwing the error when a user with with an admin group switches to a nonadmin group, reassigning to JT cuz she's just da best eva!
Comment 29 Allen W 2017-11-06 10:16:50 EST
Here's the sui pr that can follow after the above makes it in, https://github.com/ManageIQ/manageiq-ui-service/pull/1218
Comment 30 CFME Bot 2017-11-13 16:56:26 EST
New commit detected on ManageIQ/manageiq-api/master:

commit 119312ca059ac13d2155628befa5e847cc8dec3d
Author:     Jillian Tullo <jtullo@redhat.com>
AuthorDate: Fri Nov 3 11:08:52 2017 -0400
Commit:     Jillian Tullo <jtullo@redhat.com>
CommitDate: Mon Nov 13 16:22:11 2017 -0500

    Add a set_current_group method for users
    The current way of setting a user’s current_group uses resource_search, which encounters some RBAC issues. For example, when a user changes from the super administrator group to the tenant group, they are no longer able to change to the super administrator group even though it is in their MIQ groups because resource_search does not allow them to see the super administrator group. By choosing a group based off of their current miq_groups, it resolves the issue and keeps the ability to change groups consistent with that in the classic-ui.

 app/controllers/api/users_controller.rb | 22 +++++++---
 config/api.yml                          |  1 +
 spec/requests/users_spec.rb             | 76 ++++++++++++++++++++++++++++-----
 3 files changed, 82 insertions(+), 17 deletions(-)

Note You need to log in before you can comment on or make changes to this bug.