OCPBUGS-52843: Make loginMethod implementations responsible for token reviews

[everettraven]

In OCPBUGS-52843 it was discovered that the monitoring plugin for console was not present when the ExternalOIDC feature is enabled and an external OIDC provider is configured.

Upon further investigation, it looked like token reviews were failing based on the console log messages of:

E0310 10:02:30.125150 1 middleware.go:51] TOKEN_REVIEW: 'GET monitoring-plugin/plugin-manifest.json' unauthorized, invalid user token, invalid bearer token

Digging into the console code showed that the OAuth2Authenticator.ReviewToken() method was pulling the token from the session token cookie. It seems that when using the OpenShift OAuth server this cookie is the actual access token, but when an external OIDC provider is configured this is a random string that is used as a session identifier for console's backend to map to an access token.

This PR fixes this bug by moving the responsibility of reviewing the token to the configured loginMethod.

[openshift-ci-robot]

@everettraven: This pull request references Jira Issue OCPBUGS-52843, which is invalid:

• expected the bug to target the "4.19.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

In OCPBUGS-52843 it was discovered that the monitoring plugin for console was not present when the ExternalOIDC feature is enabled and an external OIDC provider is configured.

Upon further investigation, it looked like token reviews were failing based on the console log messages of:

E0310 10:02:30.125150 1 middleware.go:51] TOKEN_REVIEW: 'GET monitoring-plugin/plugin-manifest.json' unauthorized, invalid user token, invalid bearer token

Digging into the console code showed that the OAuth2Authenticator.ReviewToken() method was pulling the token from the session token cookie. It seems that when using the OpenShift OAuth server this cookie is the actual access token, but when an external OIDC provider is configured this is a random string that is used as a session identifier for console's backend to map to an access token.

This PR fixes this bug by moving the responsibility of reviewing the token to the configured loginMethod.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[xingxingxia]

From test perspective, pre-merge test result of https://issues.redhat.com/browse/OCPBUGS-52843?focusedId=26772156&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-26772156 looks good, the bug is fixed.
/label qe-approved
/test e2e-gcp-console

[everettraven]

/jira refresh

[openshift-ci-robot]

@everettraven: This pull request references Jira Issue OCPBUGS-52843, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.19.0) matches configured target version for branch (4.19.0)
• bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @xingxingxia

In response to this:

/jira refresh

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[spadgett]

/assign @TheRealJon

[TheRealJon]

@everettraven Thanks for this fix!

I have a couple of ideas:

Could we just use sessions to validate the token for standard OIDC implementation? I didn't implement this part of the code, but IIUC, sessions should only exist for valid user tokens. @liouk might have helped with sessions, and might be able to clarify.

If that's not a valid approach, is there a way that we could just implement a token-getter method on loginMethod, instead of repeating most of the ReviewToken method?

[everettraven]

Could we just use sessions to validate the token for standard OIDC implementation? I didn't implement this part of the code, but IIUC, sessions should only exist for valid user tokens. @liouk might have helped with sessions, and might be able to clarify.

I'm not following. Would you mind elaborating further what you're thinking here?

If that's not a valid approach, is there a way that we could just implement a token-getter method on loginMethod, instead of repeating most of the ReviewToken method?

We certainly could. We could also have a function that is used by each loginMethod to do the same token review process.

My reasoning for the repetition was strictly for the case of each loginMethod being able to change how token review is performed without impacting the other token review implementations. I'm not a regular contributor to this repository so I don't know how likely there would be a need for the token review implementations to review tokens differently.

For example, if we decided we wanted to validate the JWT tokens in the OAuth2 loginMethod based on some configurations in the Authentication CRD as part of the token review cycle, we could without impacting the other loginMethod implementations. Not saying this is something we will do, but something I could see being done.

[TheRealJon]

Could we just use sessions to validate the token for standard OIDC implementation? I didn't implement this part of the code, but IIUC, sessions should only exist for valid user tokens. @liouk might have helped with sessions, and might be able to clarify.

I'm not following. Would you mind elaborating further what you're thinking here?

If sessions are invalidated on logout and expire at the appropriate time, then they represent a valid user token, although I could see a few scenarios where our sessions could be out of sync with the cluster. So, I think I answered my own question there.

If that's not a valid approach, is there a way that we could just implement a token-getter method on loginMethod, instead of repeating most of the ReviewToken method?

We certainly could. We could also have a function that is used by each loginMethod to do the same token review process.

My reasoning for the repetition was strictly for the case of each loginMethod being able to change how token review is performed without impacting the other token review implementations. I'm not a regular contributor to this repository so I don't know how likely there would be a need for the token review implementations to review tokens differently.

For example, if we decided we wanted to validate the JWT tokens in the OAuth2 loginMethod based on some configurations in the Authentication CRD as part of the token review cycle, we could without impacting the other loginMethod implementations. Not saying this is something we will do, but something I could see being done.

The down side is that we have to keep both current ReviewToken methods in sync with each other if any part of the repeated code gets updated. I like the idea of at least factoring out a shared helper for the repeated logic. That still leaves room for later updates, but DRYs up the current implementation.

[everettraven]

The down side is that we have to keep both current ReviewToken methods in sync with each other if any part of the repeated code gets updated. I like the idea of at least factoring out a shared helper for the repeated logic. That still leaves room for later updates, but DRYs up the current implementation.

I'll meet you halfway and do that. I've got my own opinions on the DRY stuff, but no reason to go into a philosophical discussion here :)

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: everettraven
Once this PR has been reviewed and has the lgtm label, please ask for approval from therealjon. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• pkg/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[everettraven]

@TheRealJon Update made. Let me know if there is anything else!

[everettraven]

/retest-required

[openshift-ci]

@everettraven: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/okd-scos-e2e-aws-ovn	72f53f8	link	false	/test okd-scos-e2e-aws-ovn

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[everettraven]

/retest-required

[everettraven]

@TheRealJon Bumping this