The following branches are being fast-forwarded from the current development branch (master) as placeholders for future releases. No merging is allowed into these release branches until they are unfrozen for production release.

• release-4.5
• release-4.4

Contact the Test Platform or Automated Release teams for more information.

The following branches are being fast-forwarded from the current development branch (master) as placeholders for future releases. No merging is allowed into these release branches until they are unfrozen for production release.

• release-4.16
• release-4.17

For more information, see the branching documentation.

Hello!

Can you please advice about the license of this repo? Is it Apache 2.0 or you don't allow reuse this repo?

Thanks in advance!

It is on plan support more than one oauth-server per cluster or support sharding routers for multiple domains?

Testing on pre-release 4.10 rc2 against an OpenID Connect proxy server that was fronting a GitHub authentication backend. Discovered that if the name of a group contained in the groups list of the JWT token conaints : character that an Authentication Error will be returned:

Log from OpenID Proxy server showing contents of JWT token:

time="2022-02-16T17:02:43Z" level=info msg="login successful: connector \"github-sample-idp\", username=\"Dominique Vernier\", preferred_username=\"itdove\", email=\"[email protected]\", groups=[\"ansible\" \"ansible:acm-managed-apps\" \"stolostron\" \"stolostron:Team Red Hat\" \"stolostron:OCM\" \"stolostron:cluster-lifecycle-team\" \"stolostron:rhacm-connect\" \"stolostron:devtools-wg-admins\" \"stolostron:idp-mgmt-srv\" \"stolostron:aap-aas-demo-admin\" \"identitatem\" \"identitatem:idp-for-the-masses\"]"

Log from oauth-openshift pod on OCP:

0216 17:05:47.645020 1 errorpage.go:28] AuthenticationError: Invalid or expired code parameter.
E0216 17:05:57.246247 1 errorpage.go:28] AuthenticationError: Group.user.openshift.io "stolostron:rhacm-connect" is invalid: metadata.name: Invalid value: "stolostron:rhacm-connect": may not contain ":"

@stlaz Hoping you might can take a look? Probably too late to fix for 4.10 but maybe 4.10.1 🙏

The following branches are being fast-forwarded from the current development branch (master) as placeholders for future releases. No merging is allowed into these release branches until they are unfrozen for production release.

• release-4.6

Contact the Test Platform or Automated Release teams for more information.

Hello,
when I run podman build with the dockerfile provided in images it doesn't copy the oauth repo, due to the entry COPY . . in https://github.com/openshift/oauth-server/blob/release-4.10/images/Dockerfile.rhel#L3

Any reason for that? Shouldn't be it better to put COPY ../ . ?
Thx

As a user I would like to be able to limit login from Gitlab to a subset of users, namely users who are part of my gitlab.com group.

The following would be how I expect this feature to be exposed:

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: gitlab 
    mappingMethod: claim 
    type: GitLab
    gitlab:
      clientID: {...} 
      clientSecret: 
        name: gitlab-secret
      url: https://gitlab.com 
      ca: 
        name: ca-config-map
      # by group name
      group: mygroup
      # by email ending
      domain: mydomain.com

The Current behaviour is as follows:

Completion of the latest documentation leaves the cluster open to sign ins from any user of gitlab.com.

This leaves an issue in that there is no way to control who can sign into a gitlab application from inside gitlab, thus the client must restrict auth.

The current documented solution is to make a mapping method for an identity provider, presumably setting this to lookup as per https://access.redhat.com/solutions/5487011 , which would lead to something like https://access.redhat.com/solutions/5389931 . Mind you the documentation makes no mention of the permissive authentication, while on the google and github providers it is mentioned as a warning.

I found this PR #87 which adds a groupmapper, and found this issue https://issues.redhat.com/browse/RFE-106 which seems to be related.

Would it be possible to give Gitlab users a way to lock their sign ins to groups that isn't manual?

corresponding support request: https://access.redhat.com/support/cases/#/case/03146331

Description of the issue

ADFS implements the subjectIdentifier with "hash of client ID + anchor claim value" that will have high chances including '/' character, which should be a valid implementation as the spec states only "It MUST NOT exceed 255 ASCII characters in length".
Oauth-openshift using the subjectIdentifier to create an identity in OpenShift but the identity resources not allow '/' character, so the identity cannot be created and the user cannot login.

Version

Windows Server 2016 ADFS
OpenShift 4.3.0

Steps To Reproduce

Add an OpendID identity provider connect to ADFS.

Current Result

If user's subjectIdentifier including '/' character will encountering the following error.

oauth-openshift-685b755d6d-4z8w6 oauth-openshift E0211 16:44:00.650383       1 errorpage.go:26] AuthenticationError: invalid resource name "adfs:S//808E9UOiYKKAkagOBLGxvuLUbDCXlp8sZz6ilew8=": [may not contain '/']

Expected Result

All users are able to login.

Additional Information

Would like to see if we can use other claims for the identity name instead of sub.

• https://github.com/openshift/oauth-server/blob/master/pkg/oauth/external/openid/openid.go
• https://openid.net/specs/openid-connect-core-1_0.html#IDToken
• https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-faq

the code referenced assumes the access_token was obtained using the authorization code flow.

In the case where Openshift is configured with a OIDC Provider, it uses the ROPC flow to authenticate the client.

My understanding is that the ROPC flow OIDC Server response does not contain an id_token, and is not expected to.

As a result Openshift (4.9.18) successfully obtains an access token from the ROPC flow with the configured OIDC provider, but there is no id_token, and the following errors are reported:

I0213 11:34:24.205346       1 round_trippers.go:454] POST https://www.oauth-login.com/oidc/endpoint/OP/token 200 OK in 352 milliseconds
I0213 11:34:24.205623       1 handler.go:129] Got access data for testuser9
I0213 11:34:24.206040       1 handler.go:133] Error getting userIdentityInfo info: no id_token returned in osincli.ResponseData

I would expect either userInfo to be used, or other calls made to the OIDC provider to get an id_token

Thanks

When configuring ArgoCD to use Openshift OAuth for authentication the login works but the final code exchange fails like this inside oauth-openshift

I1013 10:29:35.684794       1 httplog.go:131] "HTTP" verb="GET" URI="/oauth/authorize?client_id=system%3Aserviceaccount%3Aargocd%3Aargocd-argocd-dex-server&redirect_uri=https%3A%2F%2Fargocd-server-argocd.apps-crc.testing%2Fapi%2Fdex%2Fcallback&response_type=code&scope=user%3Ainfo&state=qtdg2lscsyrq7qlkgutypygxi" latency="90.415571ms" userAgent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.103 Safari/537.36" audit-ID="cac191fd-8164-452d-b1ca-0040fc0a621b" srcIP="10.217.0.1:54130" resp=302
I1013 10:29:35.701586       1 request.go:833] Error in request: invalid resource name "system%3Aserviceaccount%3Aargocd%3Aargocd-argocd-dex-server": [may not contain '%']
E1013 10:29:35.701646       1 access.go:177] osin: error=server_error, internal_error=&errors.errorString{s:"invalid resource name \"system%3Aserviceaccount%3Aargocd%3Aargocd-argocd-dex-server\": [may not contain '%']"} get_client=error finding client
E1013 10:29:35.701664       1 osinserver.go:111] internal error: invalid resource name "system%3Aserviceaccount%3Aargocd%3Aargocd-argocd-dex-server": [may not contain '%']

After much digging I figured out that verbosity level 10 would dump HTTP traffic in the logs and how to increase the log level of oauth-openshift to --v=10 instead of --v=2. What I did was to scale down the authentication-operator Deployment in the openshift-authentication-operator namespace to 0, then manually edited the oauth-openshift Deployment in the openshift-authentication namespace to use --v=10.

I have not figured out what exactly has changed here but having ArgoCD do Openshift OAuth login worked fine for me about 6 months ago. After having looked quite a lot at ArgoCD and ArgoCD Operator it seems to in the end boil down to a problem in Openshift OAuth itself.

Expected result

The final code exchange works ok.

Actual result

As you can see from the log snippet above it looks like the GET request has query parameters URI escaped with a single level of escaping (which is expected and appropriate). But the error makes it seem like oauth-openshift does not unescape the client_id parameter at all.

Questions

• Can anyone versed in Openshift OAuth confirm that using a service account should provide the fully qualified name, e.g. "system:serviceaccount:NAMESPACE:ACCOUNT"?
• If not, what is the correct approach here so the ArgoCD developers can be made aware of what they are doing wrong? Keep in mind that this all seemingly worked a few months ago (but I can't swear the request from ArgoCD was identical to above).
• Is there some reason why the client_id specifically should not be URI escaped by the client making the request? I.e. do you deem it correct behavior that Openshift OAuth should NOT do one level of URI unescaping on the client_id?

Related issues

• argoproj-labs/argocd-operator#995
• argoproj-labs/argocd-operator#1012