Open Natanande opened 4 years ago
cc @reasonerjt
IMO to fix this we may allow user to set more attributes in the onboard dialog, which is a common practice.
In addition to that we may consider allow user to update his profile partially after he's onboarded.
Agreed, but since we use the "Automatic onboarding" without any onboard dialog, we would prefer specifying a claim in the oidc JWT to automatically populate the profile. For us all user information is already stored centrally in Azure.
I stumbled on this issue while trying to set up following authentication/authorization chain Harbor-2.1.1 -> Keycloak-10.0.1 -> MS AD.
From my perspective it would be enough to use value of "name" attribute returned by userinfo API.
The OpenID Connect specification defines a set of standard claims for things like the first name, last name and so on.
See: https://openid.net/specs/openid-connect-basic-1_0.html#StandardClaims
I think these claims (preferred_username
, given_name
, family_name
) should be used if no other configuration is proivided to harbor.
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.
Issue still relevant, please do not close.
Any news on this? In my opinion, it would be quite helpful if the First and Lastname
field could be set automatically during onboarding
Still a problem
We also ran into this issue when configuring Keycloak as an OIDC Provider. Not a real problem but weird, especially since the Name is known and used as the username if Username Claim
is not set.
During automatic onboarding using OIDC, the Realname is set to the username as seen here.
At my company, we set the username claim to "email", because Harbor requires the username to be unique. This results in the profile showing the email as firstname and last name, which doesn't make sense.
It would be nice to be able to set the Realname attribute to a specified claim (or a combination of multiple ones? given_name + family_name), the same way as we now can with the username and group.
This is mostly cosmetic, but it does look ridiculous when all three fields (username, email and realname) in the profile all are set to the user's email.
(Even better would be to dynamically update the realname at login/some interval, since that is something that can change)