Bug 1841519

Summary:	oauth-server with a single non-login identity provider creates a fail loop with console
Product:	OpenShift Container Platform	Reporter:	Standa Laznicka <slaznick>
Component:	Management Console	Assignee:	Jakub Hadvig <jhadvig>
Status:	CLOSED DEFERRED	QA Contact:	Yadan Pei <yapei>
Severity:	low	Docs Contact:
Priority:	medium
Version:	4.5	CC:	aos-bugs, jhadvig, mfojtik, spadgett
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	Scrubbed
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-03-09 00:58:21 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 Standa Laznicka 2020-05-29 11:16:59 UTC

Description of problem:
When configured with a single identity provider that's not capable of login authentication flows, the oauth-server returns error when accessed from the browser. When the oauth-server is accessed from the web console, this error causes redirect loop between the oauth-server and the console.

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


How reproducible:
100%

Steps to Reproduce:
1. configure request header IdP with some bogus ChallengeURL and no LoginURL
2. disable the kubeadmin user by deleting the kube-system/kubeadmin secret
3. wait for the changes to be applied to the oauth-server's deployment
4. go to the console's URL

Actual results:
The console tries to access a resource, gets "unauthorized" error, redirects user to the oauth-server, the oauth-server errors out because it does not allow browser login, redirects user to console, the console tries to access a resource, gets "unauthorized" error, redirects user to the oauth-server, the oauth-server errors out because it does not allow browser login, redirects user to console, the console tries to access a resource, gets "unauthorized" error, redirects user to the oauth-server, the oauth-server errors out because it does not allow browser login, redirects user to console, the console tries to access a resource, gets "unauthorized" error, redirects user to the oauth-server, the oauth-server errors out because it does not allow browser login, redirects user to console, the console tries to access a resource, gets "unauthorized" error, redirects user to the oauth-server, the oauth-server errors out because it does not allow browser login, redirects user to console, ...


Expected results:
The oauth-server presents the user with a login page that won't allow them to log in OR the server errors out with a clear error that tells the console not to try to loop back to it again.

Comment 1 Standa Laznicka 2020-05-29 11:21:10 UTC

The behavior is not observed in oauth-proxy

Comment 3 Maru Newby 2020-06-18 14:31:18 UTC

I’m adding UpcomingSprint, because I was occupied by fixing bugs with higher priority/severity, developing new features with higher priority, or developing new features to improve stability at a macro level. I will revisit this bug next sprint.

Comment 4 Standa Laznicka 2020-07-09 14:08:01 UTC

I’m adding UpcomingSprint, because I was occupied by fixing bugs with higher priority/severity, developing new features with higher priority, or developing new features to improve stability at a macro level. I will revisit this bug next sprint.

Comment 6 Standa Laznicka 2020-08-06 14:32:30 UTC

I noticed that the oauth-server actually behaves as expected but console does not, in words:
1. Upon entering the console's page, the browser gets redirected to https://<oauth-server>/oauth/authorize?client_id=console&redirect_uri=<url-encoded console/callback>&response_type=code&scope=user%3Afull&state=<state>
2. The oauth-server redirects the browser with error in the URL as it should according to the protocol: https://<console>/auth/callback?error=access_denied&error_description=The+resource+owner+or+authorization+server+denied+the+request.&state=<state>
3. The console's callback redirects to /error?error=missing_code&error_type=auth
4. The page responds with 200 but it appears to be still wanting to reach the API server, gets 401
5. after several API server requests, it hits /logout, /login and tries again

To reproduce this, you can simply do `oc delete secret -n kube-system kubeadmin` to disable the kubeconfig user and its web-login path and configure the oauth/cluster's spec like this:
spec:
  identityProviders:
  - name: requestHeadersIdP
    requestHeader:
      ca:  
        name: request-header-ca
      challengeURL: https://nothing.com?${query}
      headers:
      - X-Remote-User
    type: RequestHeader

Comment 8 Jakub Hadvig 2020-10-02 15:28:58 UTC

Was occupied by fixing bugs with higher priority/severity, developing new features with higher priority, or developing new features to improve stability at a macro level. I will revisit this bug next sprint.

Comment 18 Jakub Hadvig 2021-06-11 12:08:27 UTC

Still valid. Started to work on fix.

Comment 19 Jakub Hadvig 2021-07-02 16:56:26 UTC

Still valid.

Comment 23 Shiftzilla 2023-03-09 00:58:21 UTC

OpenShift has moved to Jira for its defect tracking! This bug can now be found in the OCPBUGS project in Jira.

https://issues.redhat.com/browse/OCPBUGS-8777