Description of problem: When using OST you get an engine on isolated network, that in order to make available you must tunnel. When tunnelling you end up with a URI with a odd port or hostname that will result an error while authenticating: URL: https://localhost:9000/ovirt-engine This displays this error: " The redirection URI for client is not registered " Redirection URI is something internal, which even few developers know off, and no one knows how to get around it, or make it work correctly. I haven't thought of it deep enough but I have few questions: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I get the same thing just going to the IP, https://192.168.200.4/ovirt-engine/ It's a very obscure message. Feel free to consult me for English suggestions, if you'd like.
Workaround (posted by Ravi on ovirt devel list) Create a new conf file /etc/ovirt-engine/engine.conf.d/99-sso.conf and add: SSO_CALLBACK_PREFIX_CHECK=false then systemctl restart ovirt-engine This will turn off the additional security check for the callback prefix.
I tested this and it worked for me. I think we should add it to the documentation.
(In reply to Shirly Radco from comment #3) > I tested this and it worked for me. > I think we should add it to the documentation. Agreed, and we should update the error message to something more useful.
Had the same issue when deployed HE with cockpit, got the same error when tried to log in to the engine and the work around suggested in comment#2 works for me as well.
(In reply to Greg Sheremeta from comment #2) > Workaround (posted by Ravi on ovirt devel list) > > Create a new conf file /etc/ovirt-engine/engine.conf.d/99-sso.conf and add: > SSO_CALLBACK_PREFIX_CHECK=false > > then > systemctl restart ovirt-engine > > This will turn off the additional security check for the callback prefix. That workaround will reduce security and I guess this will be for developers and QE. Most users won't do it I guess. I think we can suggest in the error which URL are registered? I know it is a bit against the 'security by obscurity', but I don't think it is harmful to expose it. Greg what do you think? can you suggest something?
The callback prefix is a OAuth 2 security measure. It is unique for each client that is registered with SSO. Exposing the callback prefix would sacrifice the security of the entire system, it would be a security hole. The reason I have not handled this yet is because from OpenID Connect and OAuth 2 point of view the message is perfectly valid.
Agree with Ravi -- can't expose the URLs. The message is valid to OAuth programmers, but it is completely obscure to normal human users :) Feel free to consult me for English suggestions, if you'd like. This situation is probably worth a longer-than-usual error message.
(In reply to Greg Sheremeta from comment #8) > Agree with Ravi -- can't expose the URLs. The URL is public URL the system is reachable at. It is there in the link of CA certificate which the user can download from the link - there is nothing secret here. Unless there should be more information there I don't know of. Anyhow some suggestions: 1. Suggest that the only valid URL is what listed in the CA (without the port) 2. if we support it - suggest in the error how to register this new URL? i.e to register the new redirect_uri (what we call internally callback_prefix I think) 3. Just say the URL being used to access the system is invalid and the system is registered under different URL. > > The message is valid to OAuth programmers, but it is completely obscure to > normal human users :) > > Feel free to consult me for English suggestions, if you'd like. This > situation is probably worth a longer-than-usual error message.
re-thinking Comment 1 If I access an engine at https://192.168.200.4/ovirt-engine/ but it needs to be accessed via name, why can't it just redirect? what's the security hole there, of giving away a DNS name? (i don't know much about oauth)
Don't forget - if the client doesn't have proper fwd/reverse records, and/or the ip changed after the fact (eg: AIO installs do wonky stuff and can change bond0 by the host installer from the UI if the actual host install fails or doens't fully rx the postreceive hook after a success) If that host install fails, the host fallsback to the primary interface slave (in my case broke the bond, and disabled it but I could access the host on the slave0 target interface being set to DHCP) before it has a chance to sets the ovirtmgt adapter). I had that issue tonight, and tested that adding the hostname to the loopback adapter line in /etc/hosts and/or fixing DNS addressed the accessibility issue from the UI.
(In reply to michael.mcconachie from comment #11) > Don't forget - if the client doesn't have proper fwd/reverse records, and/or > the ip changed after the fact (eg: AIO installs do wonky stuff and can > change bond0 by the host installer from the UI if the actual host install > fails or doens't fully rx the postreceive hook after a success) > > If that host install fails, the host fallsback to the primary interface > slave (in my case broke the bond, and disabled it but I could access the > host on the slave0 target interface being set to DHCP) before it has a > chance to sets the ovirtmgt adapter). > > I had that issue tonight, and tested that adding the hostname to the > loopback adapter line in /etc/hosts and/or fixing DNS addressed the > accessibility issue from the UI. PS: I didn't mean to hijack the thread, being that you are discussing SSO and OATH in general as it relates to the GUI error message. Just wanted to point out that I had that message, and it was related to my OP which I hope can shed some evidence of an edge case as well.
verified on 4.3.1
This bugzilla is included in oVirt 4.3.1 release, published on February 28th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.1 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.