Bug 1977054

Summary: [4.9] Unable to authenticate against IDP after upgrade to 4.8-rc.1
Product: OpenShift Container Platform Reporter: Max Whittingham <mwhittin>
Component: oauth-apiserverAssignee: Standa Laznicka <slaznick>
Status: CLOSED ERRATA QA Contact: liyao
Severity: urgent Docs Contact:
Priority: urgent    
Version: 4.8CC: aaleman, aos-bugs, bmontgom, cattias, hongkliu, mdewald, mfojtik, scuppett, surbania, wking, xxia
Target Milestone: ---Keywords: ServiceDeliveryBlocker, Upgrades
Target Release: 4.9.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of:
: 1977233 (view as bug list) Environment:
Last Closed: 2021-10-18 17:36:56 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:
Bug Depends On:    
Bug Blocks: 1977233    

Description Max Whittingham 2021-06-28 20:36:33 UTC
Description of problem:
Login via the web ui seems to redirect back to the oauth idp selection. No error is displayed in the ui, no obvious logs associated with that login event show in the oauth pods.

First time logins for both OpenShift_SRE IDP and GitHub IDP, when authenticated by the user webhook result in in-cluster User objects being created for that username. The user is not permitted access to whatever resource was being accessed (such as the cluster’s console). Subsequent access requests do not result in additional calls to the webhook (presumably because the User object already exists).


Version-Release number of selected component (if applicable):
4.8-rc.1


Actual results:
After attempting to login, webconsole redirects back to the idp selection page without an error.

Expected results:
Users should be able to login via IDP

Additional info:
Previous working version, 4.8-fc.7

Comment 1 Max Whittingham 2021-06-28 20:44:25 UTC
We have not seen this issue when deploying a new cluster at 4.8-rc.1

Comment 3 Sergiusz Urbaniak 2021-06-29 09:15:17 UTC
We found the root cause: This bug happens when a custom service account issuer is configured in conjunction with an external identity provider.

In this case oauth-apiserver would also reject bound service account tokens. We are providing a fix shortly.

The workaround is to configure a unsupported config override for oauth-apiserver.

Comment 4 Sergiusz Urbaniak 2021-06-29 09:18:14 UTC
current workaround:

unsupportedConfigOverrides: 
  oauthAPIServer:
   apiServerArguments:
    api-audiences:
    - https://custom-issuer-url

Comment 6 liyao 2021-06-30 08:39:09 UTC
Tested in sts cluster 4.9.0-0.nightly-2021-06-30-030414

1. check the custom service account issuer existed in cluser
$ oc get authentication.config cluster -o json | jq .spec.serviceAccountIssuer
"https://custom-issuer-url"

2. configure external identity provider with Google/OpenID/GitLab/GitHub/RequestHeader respectively

3. login via the web UI with different external identity provider and check whether user can login successfully
After apply the workaround, user can login successfully via web UI for all above external identity provider

Comment 9 errata-xmlrpc 2021-10-18 17:36:56 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 (Moderate: OpenShift Container Platform 4.9.0 bug fix and security update), 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/RHSA-2021:3759