Bug 1467364
| Summary: | Provisions via Users in multiple groups in tenants in SSUI result in VMs being provisioned to wrong group/tenant | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | Dustin Scott <dscott> | ||||
| Component: | API | Assignee: | Gregg Tanzillo <gtanzill> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Dave Johnson <dajohnso> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 5.7.0 | CC: | awight, bascar, cpelland, dclarizi, dscott, gmccullo, jhardy, lavenel, mpusater, myoder, obarenbo, simaishi, vparekh | ||||
| Target Milestone: | GA | Keywords: | TestOnly | ||||
| Target Release: | 5.10.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | 5.10.0.0 | 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) | Environment: | |||||
| Last Closed: | 2018-06-21 20:21:29 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | CFME Core | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1480007, 1481859, 1513191 | ||||||
| Attachments: |
|
||||||
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. :) 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 *** Bug 1473782 has been marked as a duplicate of this bug. *** *** Bug 1473783 has been marked as a duplicate of this bug. *** New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/97b099d4bafb51a4343d1aa2273924ec571ea33a commit 97b099d4bafb51a4343d1aa2273924ec571ea33a Author: Lucy Fu <lufu> AuthorDate: Thu Jul 27 17:05:38 2017 -0400 Commit: Lucy Fu <lufu> 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(-) New commit detected on ManageIQ/manageiq-automation_engine/master: https://github.com/ManageIQ/manageiq-automation_engine/commit/660b111b6bcd0546ce00fc0e99e9767a9a2a83c8 commit 660b111b6bcd0546ce00fc0e99e9767a9a2a83c8 Author: Lucy Fu <lufu> AuthorDate: Thu Jul 27 17:46:38 2017 -0400 Commit: Lucy Fu <lufu> 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(-) New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/46c7340d47815787fad2f07a5238d7b64b08a0df commit 46c7340d47815787fad2f07a5238d7b64b08a0df Author: Lucy Fu <lufu> AuthorDate: Tue Aug 8 08:51:42 2017 -0400 Commit: Lucy Fu <lufu> 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(-) What type of authentication are you configuring LDAP? Via MIQLDAP or External Auth? and or What Authentication provider(AD, OpenLDAP, FreeIPA)? 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 : https://10.8.198.75. Service name = group. Verified the group switching issue, gonna work with API team to figure out whats going on. 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! Here's the sui pr that can follow after the above makes it in, https://github.com/ManageIQ/manageiq-ui-service/pull/1218 New commit detected on ManageIQ/manageiq-api/master: https://github.com/ManageIQ/manageiq-api/commit/119312ca059ac13d2155628befa5e847cc8dec3d commit 119312ca059ac13d2155628befa5e847cc8dec3d Author: Jillian Tullo <jtullo> AuthorDate: Fri Nov 3 11:08:52 2017 -0400 Commit: Jillian Tullo <jtullo> 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. https://bugzilla.redhat.com/show_bug.cgi?id=1467364 app/controllers/api/users_controller.rb | 22 +++++++--- config/api.yml | 1 + spec/requests/users_spec.rb | 76 ++++++++++++++++++++++++++++----- 3 files changed, 82 insertions(+), 17 deletions(-) |
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: