Disabling Password Login After Configuring OIDC

[damonearp]

For security audits we need to maintain no password logins. As such I'm looking for a clean way to disable database logins after I've configured our OIDC provider and ensured at least one of us is an admin user. As a bonus for keeping security from bugging us I'd like to remove the username/password fields from the login page.

Right now best approach I see is:

• Set the admin user's deleted attribute to true update harbor_user set deleted=true where username='admin'
• Add a redirect to the nginx frontend which 302's /account/sign-in to /c/oidc/login

Is this the best approach to accomplish this?
Thanks

[wy65701436]

do you mean by disabling admin login? What about if the OIDC server is unavailable for some reason? In this situation, no one can manitain the Harbor instance.

[damonearp]

do you mean by disabling admin login?

Yes, our security policies do not allow any password based system therefore I need to find a way to disable admin login.

What about if the OIDC server is unavailable for some reason? In this situation, no one can manitain the Harbor instance.

Ideally this would be a setting in portal's & core's environment, something like SIGNIN_ENABLED=false, which would cause the sign in page to just show the OIDC login redirect button, and deny access to the webui's functionality with Basic auth. Then if OIDC is down, the SAs can alter this value and redeploy. Under this setup the admin user isn't disabled, but it is unusable. This type of configuration option is on applications like GitLab.

In what I proposed above the database needs to be updated to reenable the admin user, as well as the Nginx configuration to disable 302'ing the sign_in endpoint. Not the best but doable. I am trying to figure out if marking the admin user as deleted had any unintended consequences.

[prashi2202]

Were you able to get an answer to this query and were you able to implement, if yes then can you please share me the method followed ?

[damonearp]

There has been no discussion since October last year. We've just been marking the admin user as deleted in the database. Usage has been minimum as our deployment is just in our staging environment right now, but we are moving forward with this approach as we haven't seen any unintended side effects by "deleting" the admin user.