Harbor: [feature request]Add option to use username from oidc

[annProg]

When login with oidc, user can change their username. This may cause confusion inside the company

Describe the solution you'd like
Add an option to use username from oidc. don't allow user to change it.

[reasonerjt]

@annProg are you suggesting that we should add an option to disable user to update his username during onboard?

[annProg]

@annProg are you suggesting that we should add an option to disable user to update his username during onboard?

disable user to update his username when user first login with oidc.

[reasonerjt]

@annProg
This is essentially requiring disable user from setting his own username, I don't think it's a very reasonable requirement, esp. bear in mind that there's no guarantee the username in the OIDC provider will be presented in the token or stay unchanged.
If you want some unchanged attribute, you should use sub according to the spec:
https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims

And the sub is stored in Harbor's DB, so that's the only reliable way to trace who is who.

[jlegrone]

This came up in slack recently:

I was wondering if there is a way to "pre-configure" an OIDC user. Ideally, I would like to bypass the popup on first sign-in asking a user for their harbor username. Is there a way to have Harbor use the username passed back in the OIDC response?

I have a feeling that it is a very common use case for organizations self-hosting Harbor to want to enforce some user naming convention which can be unified with existing systems and trusted to be correct. For example, an administrator granting push access to jane.smith should know that they're not actually giving access to someone who happens to be masquerading as Jane.

Certainly the OIDC subject + issuer should be used as a primary key. However many OIDC provider implementations don't supply subject in a human-readable format, and defaulting usernames to this would make for a very poor end user experience.

I see two possible approaches, but there are likely others as well.

1. Allow administrators to configure custom policy around acceptable usernames (ie. must equal the text before @ character in email). We could provide a set of default conventions to choose from, or make this configurable with a scripting language like Lua or open policy agent.
2. Provide an option to onboard users automatically with a username matching email, or with some other transform of the OIDC data applied. Again, defaults could be supplied or this could be configurable by an administrator via scripting.

For our use cases, we want onboarding to be as seamless as possible, which is why we've patched our fork of Harbor to skip username selection and set username to email for now.

[Hokwang]

I agree with @annProg . No need to change or confirm username.

[Popsiclestick]

+1 we should be able to map to the content of the OIDC JWT

[airadier]

We are currently working on this on a repository fork at https://github.com/airadier/harbor/tree/automatic-onboard, and hopefully will share a PR in a couple of days, including:

• An option for "automatic user onboard" (don't let the user choose the username and skip onboarding screen)
• A new option to specify the username claim name in the JWT ID Token

[airadier]

Created PR https://github.com/goharbor/harbor/pull/9311 for the master branch.

[reasonerjt]

Guys thanks for your feedback, I'm convinced that this is a valid requirement. Since this change is relatively small, we can discuss the implementation in this thread instead of writing up a proposal.

@airadier could you elaborate the implementation of #9311 in this thread?

@jlegrone @Hokwang could you please also chime in to confirm this implementation suits your use cases?

If we reach agreement we can try to squeeze this change in 1.10.0, but the FC is a little close (targeting 10/25). If we miss this train, I think this can be implemented in next release.

[xaleeks]

This requirement makes sense but dips into the larger conversation of managing auth/authn on the identity management side and pulling those over to harbor, i.e. eventually grabbing more and more stuff on the jwt and mapping them to harbor components. I do get the point that the username could be very long and this removes the risk of tempering with it. We will have more discussions on this but the PR (a good one albeit) won't make the next 1.10 release which is a very short release. I'm adding a candidate/1.11 tag to this however.

[Hokwang]

@reasonerjt I can say yes it would be helpful.
@xaleeks I understand, please consider positively.
If someone's username is too long, what is the problem in harbor?
In my case, enterprise level admin manage whole employee's account and info and they provide openID and SAML to auth.
I, as a small division's admin, use that openID through Keycloak for authentication and make the group check logic (who is my division) for authorization. In this situation, we don't care username is really unique, too long or too short, whatever.

[airadier]

Hi @reasonerjt, let me elaborate about the implementation of the PR (I am copying the comments on #9311):

If the "Automatic onboarding" option is set, the onboarding screen is just skipped. There are in fact 2 (3 if you also include UI changes) big and independent changes in this PR, but they can work together:

• The first change: include option (UI + mapping to the OIDC config in core) to set a claim name for grabbing the username from. If this option is set, if will unmarshal the ID Token Json to a map[string]interface{} instead of using the JSON tags in the struct, then it will retrieve the username from the specific claim. This can work independently from the "Auto onboard" feature. So if this is enabled, but auto-onboard is disabled (default), the user will see the onboarding screen, but the preset username will be grabbed from this specific claim instead of the hardcoded one.
• If the "Auto onboard" option is checked, the OIDC callback handler will not redirect the user to the Onboard screen (when the user cannot be retrieved from the OpenID identifier, otherwise if the user already exists you this Onboard screen was already skipped), but instead, a new User is created and the onboard step is skipped.

These options work together, so you can get auto-onboarding and also get the username from a different claim (in our case, users are coming from Active Directory Federation Services, and we need the user name from the _sAMAccountName_ claim in the ID token).

In the implementation, the user onboard/creation logic has been extracted to a new userOnboard function that is called from both the controller OIDC callback and the Onboard API function (that gets called from the Onboard screen in the portal), as the user onboard/creation is the same in both cases.

Regards!

[tamirshaul]

We recently started using Harbor and would like to have this feature as well.
Is there any progress on this feature?

[bryan-taylor]

You should accept @airadier 's feature set quickly. Our desire to deploy harbor is blocked without this for two completely independent reasons.

The whole point of OIDC is to have centralized identity management so that you can use cryptographically signed data elements for security critical use cases. Allowing users to set this themselves creates the potential for social engineering attacks at worst, confusion and delay at best.

Secondly, do you validate that the username they enter here will actually work in all the contexts it needs it to?

[airadier]

Hi @bryan-taylor, let me work on some changes that are needed in my pull request, and I think it will be merged soon.

Regards!

[bryan-taylor]

Yay! So would it be likely to land in 1.11 then? I hope it's cherry-pickable, b/c we might apply it as a patch.

[jkroepke]

There is claim called preferred_username. It's a looking into the openid spec, it's a standard claim.

For Azure AD users we could also use the email claim as username since external users does have a nasty username claim.

[timcappalli]

There is claim called preferred_username. It's a looking into the openid spec, it's a standard claim.

For Azure AD users we could also use the email claim as username since external users does have a nasty username claim.

Nothing should be assumed. The claim that is used should be configurable by the Harbor admin.

[jkroepke]

Thats the best possible case. I saw a PR https://github.com/goharbor/harbor/pull/9311 so it looks like its in master and a part of the next version.

[xaleeks]

Yup, this is going to be released as part of the v2.1 coming next week, thanks to @airadier for the contribution!