harbor: Can not delete user login with oidc

@annProg This is by design, currently in Harbor any non-local user can’t be removed after on-boarded.

closing as wontfix

This is a valid issue. Those running harbor with any auth method need the ability to remove the locally made users. wontfix does not feel like the appropriate conclusion to this issue. OIDC seems to have limited functionality all throughout harbor.

Found a workaround which hopefully doesn’t break anything else 😉 :

\c registry
delete from oidc_user where user_id = xx;
delete from harbor_user where user_id = xx;

I also echo the sentiment of https://github.com/goharbor/harbor/issues/8424#issuecomment-634683478 (@wmgroot) because we are not mapping users directly to a project; rather, we are using keycloak groups to handle this.

At t0, when a new user signs up, the user is requested to create an internal user within harbor; I don’t know if this is necessary if the username (in this case a company email address) can be used from OIDC.

Anyway, if I were to go through and delete the user on the keycloak side (just for testing), harbor will not let the user log back in (I suppose because the UUID changed) even after authenticating with Harbor (our OIDC identity broker).

So, I ran into this scenario above while initially configuring all the OIDC groups and harbor projects to work properly.

In order to fix stale users, I had to run the following many times to delete non-existent users so that the real ones could log in via Keycloak. For my setup, keycloak is in an identity brokering mode so it does not directly manage any user credentials; it is handled by an IT managed authoritative Azure AD service.

Step 1: log into the database container

# Get the pod name
POD_NAME=`kubectl get pods -n harbor --output=json | jq -r -j '.items[].metadata | select(.name | startswith("database")) | .name'`
 
# Log into the pod
kubectl exec -it -n slr-system $POD_NAME -- bash
 
# Drop into the postgres sql cli
psql -U postgres
 
# Follow commands below.
# Examples:
#    username == Some.User
#    user_id  == 0

step 2: delete the user, throughout the db tables, via the user_id

\c registry

# Determine user_id
select user_id from harbor_user where username = 'Some.User';
 
# 
# Use user_id from previous step to delete the user across all the tables;
# e.g. replace owner_id = 0, user_id = 0, entity_id = 0 sections with the correct user_id
#
delete from project where owner_id = 0;
delete from oidc_user where user_id = 0;
delete FROM project_member where (entity_id = 0 AND entity_type = 'u');
delete from harbor_user where user_id = 0;

Anyway, the fact that I have to do the above is crazy as OIDC/LDAP allow this to be decoupled; I would rather give the authz configuration take precedence and let keycloak tell harbor what the user/group has access to. The guidance should be that a global identifier should be used for the user; in my case, an immutable global identifier is an employee’s email address.

So, ideally, in each webui view we would check if the user is logged in via harbor local database, ldap, or if there is a JWT from OIDC (e.g. no local username is required AFAIK).

My recommendation would be that if there is a user defined in the local database, then clearly the harbor admin wants to use harbor managed users. However, if LDAP/OIDC is used, then the authoritative source should be those systems. If a user named “employee.1@company.com” is using harbor, and temporarily leaves the company, then comes back; then the resources of that “employee.1@company.com” should be accessible by them. Harbor does not need to manage if the user exists or not; just track the mappings by OIDC UUID or by email address.

We could solve this issue by

1. Enable delete user button for other auth_mode
2. Remove the user from the project member
3. Delete the user’s OIDC token-related info when auth_mode is oidc_auth.
4. “Soft delete” the user from harbor_user.

If the deleted user created a project before, the project exists after the owner deleted, and the admin could manage its privileges.

Hi, We encountered similar issue with Keycloak. After deleting the user inside keycloak and recreate one with the same name, the user will not be able to login to harbor with oidc anymore. We have to delete the user in harbor or it’s locked out forever. I guess the only option is to drop the harbor user in db directly.

FYI From version 2.4 on Harbor supports deleting OIDC user.

I honestly don’t get why this issue is such a problem to resolve. 😃 Allow admins to delete the oidc-created user, if that user later logs in again, just recreate it. Easy peasy!

Guys, the problem is there’s disconnection between Harbor’s DB and the ID provider. Allowing admin to remove a user, when that removal happens, the user may still exists in the ID provider. We need to consider the case after jack is removed from Harbor’s DB, what if the user jack login via OIDC provider again?

That’s simple: the user is recreated. This request is about a feature for Harbor-Admins to clean up after testing, possibly after deleting the test user on the ID provider, or to re-test the onboarding workflow without creating a new user on the ID provider.

It is not about a way for users to change their username.

It feels like a rather arbitrary limitation to not allow admins remove users in Harbors database only because they have been provisioned through OIDC.

Harbor is an amazing product that we use without any major issues in production. It works really VERY well. This issue here is an extreme outlier.

What is the point of having delete user option when it is not usable? Either fix it or remove it… It just confuses the people. IMO this should be added.

I agree with verwilst’s complaints that there isn’t a valid workflow to recreate or change attributes about users who are created via OIDC. I don’t think manually modifying values in postgres is intended to be the canonical workflow to address these issues. I think the need for this feature is simple and valid, and should be revisited.

@dkulchinsky

It’s my belief that being honest and frank is respectful. I don’t disagree that Harbor is a great product, but no traction on a 2 year old issue is upsetting from a perspective of those of us users that face this real corner case more often than you’d think. It doesn’t give users confidence that this issue and issues like this will be resolved anytime soon.

Not being able to handle this in an automated fashion means unnecessary manual intervention to resolve when it does come up and in the case of the env it’s hosted in on my side, this is quite an involved process.

How is this a wontfix? We’re having the same issue as @kkzxak47 , where we have a couple of test users that are now stuck there forever, and a person who entered his full name instead of his username. Both can’t be deleted/renamed ( and i can’t seem to find it in the postgres db so delete/rename manually). An option to delete the ‘local’ copy in Harbor would be much appreciated. Whenever the user logs in again through OIDC, a new user can be created.

This is by design, currently in Harbor any non-local user can’t be removed after on-boarded.

It would be very interesting to see the discussion regarding that design decision, and see what we can do about it. I’ve tried looking around for design documents, but I have failed to find any. If @reasonerjt or someone else can point me in the right direction, that would be much appreciated!

Clearly this is a desired feature for many Harbor users, and I see no reason for this being the right design per se. On the contrary, I can think of multiple good reasons for changing this design. So perhaps we can have a discussion about it here and try to figure out a better way forward. But that requires attention from at least one maintainer that can speak up on behalf of the project.

We would be happy to contribute with improvements, but doing so without the maintainers’ blessing would be somewhat a waste of time. So I hope we can discuss it first just to know we’re aiming in a viable direction.

2 year old issue still not solved and no breath of progress from the developers, this doesn’t look like it will get traction anytime soon. It seems Harbor isn’t going to be GDPR compliant and that raises the question “Is it even fit for usage in production?”

Harbors front page says “Our mission is to be the trusted cloud native repository for Kubernetes”. If that’s true, then they should give admins the ability to remove non-local users so we can control access in a cloud native way.

@reasonerjt why don’t we just discuss on this ticket, I’m reopening to work this through.

The reason why this we don’t allow deleting non-local users is there is no way to tell the difference btw user being deleted on the OIDC side or they just entered the wrong credentials. That information doesn’t come through to us on the token, Dex is just fronting for the authn back-end even and it just handle connecting harbor with the back-end. So if we allow deleting on harbor, that would be problematic if it was actually someone else attempting to login. I think most of the users are wanting to delete a username that they mistyped but that will be mitigated by this PR where we don’t provide them with that option, the username is taken directly from the OIDC provider - https://github.com/goharbor/harbor/pull/9311

What if we create a UX workflow that allows user to confirm deleting in Harbor but they bear the responsibility of re-adding that user to all the projects and so on if they accidentally deleted the wrong user

I am able to delete the harbor user which is onboarded from OIDC (Keycloak) but its manual process. Isn’t like deleting a user from keycloak for harbor client deletes from harbor database itself automatically ? why admin has to delete the user from harbor explicitly ?

How should Harbor know if the user is deleted from the IDP? If you want to automate that, add a webhook to your IDP to trigger a user deletion in Harbor, when a used is deleted in the IDP.

+1 from me. It has to be possible to delete a user account, at least when the user has disappeared from ldap.

This is important to be compliant with the GDPR where user accounts have to be deleted (or anonymized) after a certain time after the user has left the organisation. Thanks to @n0rig for the instructions to remove the user directly from the database - but there should be a working api call

I have the same use-case than @jmichelgarcia.

I would be happy with an UI that allows to just delete an user that owns no projects, and allows to transfer projet owner_id to another user to keep the relational DB happy.

I understand that user will be removed from all projects, and all of their permissions will be reset. That isn’t a problem for me, because our project permissions are group-based, so nothing depends directly on the user.

If I’m already having to remove users from the database directly (potentially for compliance reasons after an employee leaves, as jonhatallasf mentions), why not simplify the process with a confirmation box that warns the user?

I also had the issue, in my case I migrated our users to another issuer, their uuid changed but not the email/username. So I just needed to update the subiss column of the table oidc_user to retrieve my users. Luckily for me I only had 10 users to change…

1st run: select h.user_id, o.subiss, h.email from harbor_user h inner join oidc_user o on o.user_id = h.user_id;

then for every user: update oidc_user set subiss = 'the-new-user-uuidhttps://mynewissuer.com/auth/realms/myrealm' where user_id = 13;

Harbor is an amazing product that we use without any major issues in production. It works really VERY well. This issue here is an extreme outlier.

@rhuitl thank you for saying that ☝🏼 and going to say I completely agree! I think this project has a very dedicated team that are doing a lot of work to improve and enhance the product and we highly appreciate all their work and support! ❤️

we may have some disagreements and I tend to agree with the overall ask here to be able to easily drop OIDC users if needed, our concern is not GDPR related but actually a real corner case where a user left the company and later came back and couldn’t get onboarded since a user with the same email (but different sub id) already existed, we were able to work around that and it’s a rare corner case.

but in the end, there’s a team that drives the project and need to make decisions, we may disagree but the right approach is to share our opinion in a respectful way and I think overall the team has an open mind.

They can’t login anymore but does all the robot account and other cli-credential removed also?

1. It seems not, I can remove a user access from the OIDC, but since it still exist in the database he would have access to it.
2. It’s against law at least in EU, any user can request to delete information about them in every IT system. Removing only access to harbor while keeping a record of them in the database is not an option.

Having to workaround directly in the Database isn’t a good option and if many people express the same need, maybe there’s one ! A small cli that would do that as suggested by @bsctl would work great.

@reasonerjt what about provide a cli command to remove safety a deleted OIDC user from the db?

@rhuitl

The decision was if a user was onboarded to Harbor via external IDP such as OIDC / LDAP, he can’t be removed from Harbor’s DB, instead, he should be removed from external IDP so he can no longer log in to Harbor.

When the user is recreated, will he have the membership he previously had? It is not simple to make things consistent across all external IDP. If we make the behavior different from OIDC onboarded user to LDAP onboarded user, things can also get confusing, and the workflow is hard to maintain, we want to avoid that.

That’s why I suggest we think it through before make any quick fix or decision.