Bug 1977054 - [4.9] Unable to authenticate against IDP after upgrade to 4.8-rc.1
Summary: [4.9] Unable to authenticate against IDP after upgrade to 4.8-rc.1
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oauth-apiserver
Version: 4.8
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.9.0
Assignee: Standa Laznicka
QA Contact: liyao
Depends On:
Blocks: 1977233
TreeView+ depends on / blocked
Reported: 2021-06-28 20:36 UTC by Max Whittingham
Modified: 2021-10-18 17:37 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
: 1977233 (view as bug list)
Last Closed: 2021-10-18 17:36:56 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift cluster-authentication-operator pull 458 0 None closed Bug 1977054: observe api-audiences for the oauth-apiserver 2021-07-06 19:07:26 UTC
Red Hat Product Errata RHSA-2021:3759 0 None None None 2021-10-18 17:37:20 UTC

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):

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:

    - 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

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.


Note You need to log in before you can comment on or make changes to this bug.