You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I am running Harbor in Kubernetes and using an OIDC Provider for Authentication. I defined a OIDC Admin Group in the Authentication Configuration. My OIDC User is Member of the Admin Group but when I generate a cli secret, the secret do not have the same permissions as the admin user.
Describe the solution you'd like
My expectation would be that I my cli-secret have the same permissions like the admin user.
It could be a limitation for OIDC auth.
Because the admin group feature requires the user's group information to grant admin permission when the user login.
When login with the cli, the auth middleware can't get the user's group information.
The original intention of the OIDC cli secret is used to call /v2/ API, not used to call /api/v2.0/ API
Hi,
I agree CLI secret is targeting cli but IMO it's very doable that the auth middleware gets the group information.
The CLI secret is bound to the id token, so when the cli secret is verified the middleware also verifies the id token and at that time we probably can get the groups' info that is encoded in the token.
Is your feature request related to a problem? Please describe.
I am running Harbor in Kubernetes and using an OIDC Provider for Authentication. I defined a OIDC Admin Group in the Authentication Configuration. My OIDC User is Member of the Admin Group but when I generate a cli secret, the secret do not have the same permissions as the admin user.
Describe the solution you'd like
My expectation would be that I my cli-secret have the same permissions like the admin user.
#18730
goharbor/terraform-provider-harbor#328
The text was updated successfully, but these errors were encountered: