Bug 1498984
| Summary: | DB/LDAP User is not able to log into SSUI | |||
|---|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | Shveta <sshveta> | |
| Component: | API | Assignee: | Gregg Tanzillo <gtanzill> | |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Matt Pusateri <mpusater> | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | 5.8.0 | CC: | abellott, awight, chhale, cpelland, dclarizi, jhardy, mpusater, obarenbo, simaishi, sshveta | |
| Target Milestone: | GA | Keywords: | Regression, TestOnly, ZStream | |
| Target Release: | 5.9.0 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | auth:db:miqldap:ad:ssui | |||
| Fixed In Version: | 5.9.0.2 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1499868 (view as bug list) | Environment: | ||
| Last Closed: | 2018-03-06 14:46:02 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: | 1499868 | |||
| Attachments: | ||||
|
Description
Shveta
2017-10-05 18:15:23 UTC
Appliance : https://10.8.197.195/ui/service/ I'm seeing this with MIQLDAP and AD too. In one case the UI sits there and doesn't do a thing. Looking in logs, the users is denied due to being in a group that doesn't have permissions. But 1. Nothing is returned to the user and 2. The group that the user is being evaluated against, the user is not a member of that group. What username / password should I use? Interestingly enough on the second server the logs are showing that test-user4 and the default admin user are being denied access due to group user-group-ad. Neither of those users are in that group. So groups are not being evaluated properly. It looks like previous user's groups are being held over like the group variable is not being re-initialized each time.
Also user-group-ad is mapped to EvmRole-auditor, which I think should have SSUI rights.
[----] I, [2017-10-05T14:53:27.341425 #2343:19b5dc4] INFO -- : Generating Authentication Token for userid: test-user4@
ad.cloudqe.bos.redhat.com requester_type: ui
[----] I, [2017-10-05T14:53:27.344337 #2343:19b5dc4] INFO -- : MIQ(Api::AuthController.log_request) Response: {:
completed_at=>"2017-10-05 18:53:27 UTC", :size=>"0.102 KBytes", :time_taken=>"0.507 Seconds", :status=>200}
[----] I, [2017-10-05T14:53:27.386329 #2343:19b5dc4] INFO -- : MIQ(Api::AuthController.log_request_initiated)
[----] I, [2017-10-05T14:53:27.386606 #2343:19b5dc4] INFO -- : MIQ(Api::AuthController.log_request) API Request: {:
requested_at=>"2017-10-05 18:53:27 UTC", :method=>"GET", :url=>"https://10.8.198.87/api/auth?requester_type=ws"}
[----] E, [2017-10-05T14:53:27.392026 #2343:19b5dc4] ERROR -- : MIQ(Api::AuthController.api_error) API Error
[----] E, [2017-10-05T14:53:27.392092 #2343:19b5dc4] ERROR -- : MIQ(Api::AuthController.api_error) Api::AuthenticationE
rror: Invalid Authorization Group user-group-ad specified
[----] I, [2017-10-05T15:14:29.333076 #2343:19bd1a0] INFO -- : MIQ(Api::AuthController.log_request_initiated)
[----] I, [2017-10-05T15:14:29.333314 #2343:19bd1a0] INFO -- : MIQ(Api::AuthController.log_request) API Request: {:
requested_at=>"2017-10-05 19:14:29 UTC", :method=>"GET", :url=>"https://10.8.198.87/api/auth?requester_type=ui"}
[----] I, [2017-10-05T15:14:29.433874 #2343:19bd1a0] INFO -- : MIQ(Api::AuthController.log_request) Authentication: {:
type=>"basic", :token=>nil, :x_miq_group=>nil, :user=>"admin"}
[----] I, [2017-10-05T15:14:29.435390 #2343:19bd1a0] INFO -- : MIQ(Api::AuthController.log_request) Authorization: {:
user=>"admin", :group=>"EvmGroup-super_administrator", :role=>"EvmRole-super_administrator", :tenant=>"My Company"}
[----] I, [2017-10-05T15:14:29.436179 #2343:19bd1a0] INFO -- : MIQ(Api::AuthController.log_request) Request: {:method=>:get, :action=>"read", :fullpath=>"/api/auth?requester_type=ui", :url=>"https://10.8.198.87/api/auth?requester_type=ui", :base=>"https://10.8.198.87", :path=>"/api/auth", :prefix=>"/api", :version=>"2.4.0", :api_prefix=>"https://10.8.198.87/api", :collection=>"auth", :c_suffix=>"", :c_id=>nil, :subcollection=>nil, :s_id=>nil}
[----] I, [2017-10-05T15:14:29.436670 #2343:19bd1a0] INFO -- : MIQ(Api::AuthController.log_request) Parameters: {"requester_type"=>"ui", "action"=>"show", "controller"=>"api/auth", "format"=>"json", "body"=>{}}
[----] I, [2017-10-05T15:14:29.437725 #2343:19bd1a0] INFO -- : Generating Authentication Token for userid: admin requester_type: ui
[----] I, [2017-10-05T15:14:29.440139 #2343:19bd1a0] INFO -- : MIQ(Api::AuthController.log_request) Response: {:completed_at=>"2017-10-05 19:14:29 UTC", :size=>"0.102 KBytes", :time_taken=>"0.107 Seconds", :status=>200}
[----] I, [2017-10-05T15:14:29.479767 #2343:19bd1a0] INFO -- : MIQ(Api::AuthController.log_request_initiated)
[----] I, [2017-10-05T15:14:29.479997 #2343:19bd1a0] INFO -- : MIQ(Api::AuthController.log_request) API Request: {:requested_at=>"2017-10-05 19:14:29 UTC", :method=>"GET", :url=>"https://10.8.198.87/api/auth?requester_type=ws"}
[----] E, [2017-10-05T15:14:29.486200 #2343:19bd1a0] ERROR -- : MIQ(Api::AuthController.api_error) API Error
[----] E, [2017-10-05T15:14:29.486273 #2343:19bd1a0] ERROR -- : MIQ(Api::AuthController.api_error) Api::AuthenticationError: Invalid Authorization Group user-group-ad specified
After changing the primary group I was able to login. I feel this is a dup of https://bugzilla.redhat.com/show_bug.cgi?id=1437682 but, Matt feels otherwise. Going to send this to API team for review. The Invalid Authorization Group error from the API is when the specified group in the API request (as per the X-MIQ-GROUP specified in the Httpd header) is not a valid group for that user in the database. We've tried an API Get on the first server with dbtestuser1 with X-MIQ-GROUP user-group-ad, that fails with the 401 because that's not a valid group for that user. If we try the API GET with the X-MIQ-GROUP of EvmGroup-operator, that works fine as expected. Question is how is the user-group-ad obtained initially in the SUI ? The scenario for user-group-ad only applies to the second server which doesn't have dbtestuser1 in it. So you need to retest what you did against the 2nd server. Also tested on second server, API is behaving correctly. I've run API gets on all test-user1-4 with X-MIQ-GROUP of user-group-ad. 1-3 succeed 4 fails because test-user-4 is not a member of that group. Question above remains. Also tested on second server, API is behaving correctly. I've run API gets on all test-user1-4 with X-MIQ-GROUP of user-group-ad. 1-3 succeed 4 fails because test-user-4 is not a member of that group. Question above remains. Chris H is going to answer the question from Alberto. FWIW - I was just able to login to the 2nd server with the logins specified. Alberto! Hi. Answering your question above, sui does a
`$http.get('/api?attributes=authorization', config)`
then sets the X-MIQ-Group to the `response.data.identity.group` result of that call, this is how we first set the var.
When the user switches groups (via api), we set X-MIQ-Group to the response.description result of a `POST api/users` with option
{'action': 'edit','current_group': {'id': group.id}}
Group setting occurs here.
https://github.com/ManageIQ/manageiq-ui-service/blob/master/client/app/core/session.service.js#L32
If it would help, we can 👖
I think I just figured out how to reproduce this. 1. Try to log into the SSUI with a user that should not have perms. Like EvmGroup-user. It should fail as expected and you get a flash message as expected of "Error! You do not have permission to view the Service UI. Contact your administrator to update your group permissions" 2. Change the username and password to a user with permissions. Click Log In. Nothing happens in the webui, but api.log shows successful authentication, but authorization fails with the group of the user in step 1. OH OH OH you know... we don't delete the x-miq-group headers when destroying the session... though they get set every time... maybe that has something to do with it... Matt, your appliance still humming? Yeah, it's still up plus I have a 3rd if need be. @Matt, ok so is that the issue? What was mentioned above? Ends up we were throwing an error when login failed, but no destroying the session... If so I'll wrap this change up into a pr and send it on its way... @Matt, check it out here https://github.com/ManageIQ/manageiq-ui-service/pull/1061 Tested db and miqldap-ad on 5.9.0.2 Weird this worked for DB logins and external auth - AD. But it's failing for External auth FreeIPA. I get kicked back to apache login form. Nothing seems to get written in the audit or evm logs. Created attachment 1342869 [details] API: Server returned a non-200 response: 400 Bad Request So logging into ops with the provided credentials I see this error: URL https://10.8.198.202/api/auth?requester_type=ws Status 400 Bad Request Content-Type application/json; charset=utf-8 Data {"error":{"kind":"bad_request","message":"wrong number of arguments (given 1, expected 2)","klass":"ArgumentError"}} Gonna need to tag someone else in for help on this one. Created attachment 1342870 [details]
API: Server returned a non-200 response: 400 Bad Request additional info
So when logging into the classic UI I see this: https://bugzilla.redhat.com/show_bug.cgi?id=1505922 But I don't get that same error when hitting the SSUI, at least not presented to me. Created attachment 1342900 [details]
Error message can be found on network tab of dev console
Also, here: https://github.com/ManageIQ/manageiq-ui-service/pull/1142#pullrequestreview-71617328 ChrisH added the server response to the message It looks like JoeV has already addressed the 400 - bad_request issue with this PR - https://github.com/ManageIQ/manageiq/pull/16386. Please retest with the latest build. Verified: 5.9.0.17 The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |