OIDC via ldap: failed to create user record user or email already exists

[andreas-p]

For a while now, we have intermittently the problem that one user cannot login via OIDC: failed to create user record: user "The user" or email "user@somewhere" already exists. This happens on a single user, whether automatic onboarding is enabled or not.

The message is actually correct, both user and mail are present in the system, for that very user. Checking the tables harbor_user and oidc_user, I don't see any difference between users that work normally, and the one who doesn't.

Previously, I deleted the user (didn't own resources back then), and he on-boarded automatically again, but this hotfix won't work in the future.

Currently on 2.4.1, according to the changelog 2.4.2 doesn't promise differently.

So somehow the user isn't re-detected, why? (ldap uid never changed)

[stonezdj]

Could you please try to login with the failed user and upload the core.log?

[andreas-p]

loglevel up to debug:

[/server/middleware/log/log.go:30]: attach request id aa5a3ee5-f37f-4e7d-8207-e11ea5e5a0f6 to the logger for the request GET /c/oidc/callback
[/server/middleware/artifactinfo/artifact_info.go:53]: In artifact info middleware, url: /c/oidc/callback?code=...
[/server/middleware/security/unauthorized.go:28][requestID="aa5a3ee5-f37f-4e7d-8207-e11ea5e5a0f6"]: an unauthorized security context generated for request GET /c/oidc/callback
[/pkg/oidc/helper.go:209]: Raw ID token for verification: eyJhbG...
[/pkg/oidc/helper.go:209]: Raw ID token for verification: eyJhbG...
[/core/controllers/oidc.go:132]: Doing automatic onboarding
[/core/controllers/oidc.go:193]: User created: John_Doe 
[/lib/http/error.go:59]: {"errors":[{"code":"UNKNOWN","message":"failed to create user record: user John_Doe or email [email protected] already exists"}]}
[/core/controllers/oidc.go:140]: User not onboarded

[stonezdj]

Please check the following information.

docker exec -it harbor-db bash
psql -U postgres -d registry
# get user id
select * from harbor_user where username = 'John_Doe' 
# query subiss from oidc_user
select * from oidc_user where user_id = <user_id>

Check the current user's OIDC auth token and find the subject and issuer, make sure the subject + issuer is identical to the subiss column in the database.

[andreas-p]

I see strange stuff in oidc_user.subiss. For example, there's a login mrdev via ldap, it was onboarded last:

CgVtcmRldhIEbGRhcAhttps://dex.internal.server:443/ Trying to decode64 this, invalid chars are detected. Adding ==, decoding CgVtcmRldhIEbGRhcA==https://dex.internal.server:443/ resolves to 0a 05 6d 72 64 65 76 12 04 6c 64 61 70 |..mrdev..ldap| which looks better to me.

Actually, I find that all users that can successfully login, also have such corrupted subiss entries. In contrast, the user that can't login, is base64-decodable without patching the subiss column. This is quite the opposite of what I'd expect.

[stonezdj]

@andreas-p is it a configuration issue in OIDC?

[andreas-p]

@stonezdj I dont think so.

[github-actions[bot]]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[andreas-p]

Still no clue how to continue.

[dtwork2022]

+1 We are also experiencing this issue as well. The pattern tends to be oidc_user.subiss empty on users that get the error. Deleting the user account has been our workaround.

[github-actions[bot]]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[andreas-p]

still no progress

[lknite]

also experiencing this ... probably just going to reinstall and start over

[github-actions[bot]]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[andreas-p]

..

[github-actions[bot]]

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 30 days with no activity. If this issue is still relevant, please re-open a new issue.

[fitz123]

.. no ldap, just dex oidc gives us such issue too

[lknite]

Experiencing this again after changing oidc client secret, submitting new issue in case my situation might be slightly different even though the error message is the same: https://github.com/goharbor/harbor/issues/16558

Hopefully can get a workaround, even if the issue isn't fixed... maybe by editing the postgresql database or something ...