Bug 2015550

Summary: MTC web console displays "Authentication Failed" message during login
Product: Migration Toolkit for Containers Reporter: Abhijeet Sadawarte <asadawar>
Component: UIAssignee: Ian <ibolton>
Status: CLOSED ERRATA QA Contact: ssingla
Severity: urgent Docs Contact: Avital Pinnick <apinnick>
Priority: urgent    
Version: 1.6.0CC: dagur, ernelson, ibolton, jmatthew, jmontleo, morgan.peterman, mperetz, rjohnson, rpalathi
Target Milestone: ---   
Target Release: 1.6.2   
Hardware: Unspecified   
OS: Unspecified   
URL: https://github.com/konveyor/mig-ui/issues/1353
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-11-10 11:48:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Abhijeet Sadawarte 2021-10-19 13:31:12 UTC
Description of problem:
I have 2 customers reporting issues accessing the MTC route and getting 'Authentication Failed' on the browser and mig-ui pod logs shows "Access Token Error The content-type is not JSON compatible"
The other routes including OCP console work just fine.

The mig-ui pod log shows "Access Token Error The content-type is not JSON compatible" errors.

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

How reproducible:
- Install MTC operator and create a migration-controller instance. Try accessing the mig-ui console and it fails with the 'authentication failed' error.

Comment 3 Erik Nelson 2021-10-27 16:42:39 UTC
I was going to file a distinct bug for this, but instead I'll keep the details here and we can use this bug to track. Details of the issue after we've been able to pinpoint the root cause:

1.6.0 released a change in the mig UI's server that repaired a bug where the proxy
details were never actually respected by the various client calls made during
request proxy, as well as the token exchange done to faciliate oauth login.

During this change, a regression was introduced that causes the token exchnage
process to ignore the NO_PROXY setting, and instead only use the proxy settings
to perform its token requests.

This can result in broken authentication that prevents a user from being able
to log in to the migration UI. To be clear, API driven migrations are unaffected.
The reason this breaks could be that the proxy exists outside of the intranet
such that it's unable to reach the token exchange endpoint or the oauth service
at all that resides inside of cluster network. As an example, if you have all
your nodes on a "foo.mycorp" domain, and your proxy exists outside of this, and
the proxy cannot resolve this, you'll end up proxying the token exchange to an
address that's inside of "foo.mycorp". Since the proxy cannot resolve this address,
the request, and therefore the authentication sequence will fail.

Steps to reproduce:
1) Configure a restricted environment with no external network communcation except
for that via a proxy server. This proxy server must not be able to resolve, or
route Openshift Route addresses that exist in the cluster.

2) Configure the global proxy settings to utilize this proxy server.

3) Attempt to log into the MTC UI

Actual results
An error is returned from the proxy to the mig ui's node server that is probably
not JSON mime-type, causing an error to be surfaced that may specify something
like "unknown Content-Type" or "unexpected Content-Type". It will fail to login
to the UI.

Expected results:

Login should succeed

A related bug was fixed during the 1.6.0 bug fix phases, as a point of reference:
https://bugzilla.redhat.com/show_bug.cgi?id=1939704

Comment 18 errata-xmlrpc 2021-11-10 11:48:18 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Migration Toolkit for Containers (MTC) 1.6.2 release advisory), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4608