Bug 1467364 - Provisions via Users in multiple groups in tenants in SSUI result in VMs being provisioned to wrong group/tenant [NEEDINFO]
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: Provisioning (Show other bugs)
5.7.0
Unspecified Unspecified
high Severity high
: GA
: 5.9.0
Assigned To: Lucy Fu
Shveta
: TestOnly, ZStream
: 1473782 1473783 (view as bug list)
Depends On:
Blocks: 1480007 1481859
  Show dependency treegraph
 
Reported: 2017-07-03 10:19 EDT by Dustin Scott
Modified: 2017-09-18 09:51 EDT (History)
9 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 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mpusater: needinfo? (dscott)


Attachments (Terms of Use)

  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):

5.7.2.1


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.  

Chris
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:
https://github.com/ManageIQ/manageiq/commit/97b099d4bafb51a4343d1aa2273924ec571ea33a

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.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1467364

 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:
https://github.com/ManageIQ/manageiq-automation_engine/commit/660b111b6bcd0546ce00fc0e99e9767a9a2a83c8

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.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1467364

 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:
https://github.com/ManageIQ/manageiq/commit/46c7340d47815787fad2f07a5238d7b64b08a0df

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.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1467364

 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)?

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