Harbor: when using OIDC, support group(or role) like LDAP memberof

[Hokwang]

Is your feature request related to a problem? Please describe.
I am testing harbor 1.8.0 version,
installed in local kubernetes using your helm chart.

I am using keycloak which is an IAM tool for oidc connect (like dex).
and I succeeded harbor integrated with keycloak.
But I need "mapping oidc's group (or role) to harbor's group" feature,
as you know the project permission management should not be done after the user has joined, but before the user is registered.

I guess you can use 'memberOf' key like LDAP,
and please check below links, it is how to use oidc's group example for jenkins.
http://devopsku.be/setup/jenkins-keycloak/
https://github.com/jenkinsci/oic-auth-plugin/issues/8

I can't find latest images, so I captured my jenkins screen.

This will be helpful to other harbor admins and who considers automation.

[reasonerjt]

Is the support of group a part of OIDC spec?
The difference between OIDC and LDAP, is that we can check the existence of a group in LDAP and onboard it to Harbor, then assign a role to group, but I don't think we can do that in OIDC.

[loosi]

Groups can be easily provided by a claim. It's basically a custom claim that can be added pretty easy in the end (flat list, nested list, or whatever). Lots of OIDC provider support that claim out of the box

[reasonerjt]

@loosi
That will only add the group into the claim of the token, but we cannot verify if a group actually exist or not. So user cannot onboard the group and assign it to a project as member as what we are doing for LDAP.

[Hokwang]

@reasonerjt
For the clarify,

1. I want to show you that tool can provide the ability to enter claims (custom also OK)
2. Like LDAP's memberOf, I think it is just key and value and value can be list(array),
   you can use some custom claim for group and if provided,
   I really want to use below scenario.
3. harbor install
4. integrated oidc
5. create A project for A team and then add A group to developer(whatever role) in member tab
   (Assume that oidc already has many groups and many users.)

I think you don't care "A group is actually exist or not", all you have to do is that admin can add the group in member tab.

and please think about the current situation,
user can log in via oidc, but after log in, they request to admin for adding to member every time.

[loosi]

@reasonerjt
I dont't really get your problem - maybe you could clarify that.
Do you need to verify that the groups exists forehand? How is the Workflow for LDAP Accounts now, if the groups does not exist?

[rofafor]

I'd like to see this feature as well. The group onboarding could be implemented via an API endpoint or webhook allowing full automation.

[reasonerjt]

@loosi
For LDAP admin can add an LDAP group to as a member of project, and after that any user belongs to that group will have the membership, without having to be added to the group, but Harbor will verify the group exists in the LDAP.

[reasonerjt]

@Hokwang
I understand the workflow you are trying to propose, but allowing user to add a group as a member without any checking may cause negative effect. We'll need to have more discussion with other maintainers before making the decision.

[Hokwang]

@reasonerjt
I understand. Please consider enterprise harbor admin's maintain user permission and automation perspective. I have lots of teams and over 2000 users.
I think you don't need to verify group exist in LDAP. (oidc too)
Because user who does not have the group will not pull/push that project and then user realizes that he/she does not have the group.
I guess there's no system effect.
I hope the discussion on this issue will be done as soon as possible and reviewed positively.

[erwinntt]

We from NTT DATA also evaluate Harbor with OIDC (Keycloak). But currently we can not use it because there is no way to map Keycloak roles to Harbor groups.

The solution could be JWT as used in the OpenDistro Elasticsearch. After a login with Keycloak a JWT access token is retrieved that looks like this:

  ...
  "address": {},
  "email_verified": true,
  "roles": [
    "admin"
  ],
  "name": "Admin Admin",
  "preferred_username": "admin",
  "given_name": "Admin",
  "family_name": "Admin",
  "email": "[email protected]"
}

As you can see there is a roles there with admin as the role. This is then mapped to the internal Elasticsearch role admin.

    admin:
      readonly: true
      hash: the_hash
      roles:
        - admin
      attributes:
        attribute1: value1
        attribute2: value2
        attribute3: value3

Maybe in Harbor you could implement the same. The JWT access token could include a role and the user is then assigned to the Harbor group that matches that role.

[drehpehs]

Agree with @Hokwang
I think harbor doesn't need to verify the group existed or not in LDAP or OIDC.
Currently in Jenkins with Openid Connect setting, we still can assign user/group to roles without checking the existence. Users have no permission in the role because they are not in that nonexistent group.

[reasonerjt]

@erwinntt I think that's a different problem you mentioned? Could you open another issue to better

And I think ID token is for authn not for authz?

[devent]

@reasonerjt No, it's related to the original issue "mapping oidc's group (or role) to harbor's group"

In Keycloak you can create client roles and attach those roles to the ID token. Then in Keycloak you can add users to those roles and the roles will be returned in the ID token.

All is needed for Harbor is to read the ID token roles and map them to the group. The user is then assigned to the Harbor group.

(I just realized that there are no Harbor groups without an LDAP. But there are still roles like "project admin", "developer", etc.).

[reasonerjt]

@devent
Sorry for the late response.

Just to clarify I don't think we are going to support mapping roles in oidc token to roles in Harbor.

Are you suggesting Harbor view the roles in token by keycloak as groups?
Will the screenshot in OP satisfy the requirement, that admin set a claim for group list? in the case by @erwinntt , "roles"?

[zetaab]

@reasonerjt I coded something which looks like this https://github.com/goharbor/harbor/commit/afc98356cb2a1f882cf42d4b9b542226869bb9e8

• user_groups are always went through when new/existing user will login, this way we can populate user_groups table
• authentication to /service/token missing, can we read oidc token in that function? If not, then we could save groups to user model when user will login. I know - its not the best way but it is still step forward. (means that if you want update groups you need relogin, we could also make some "resync groups" button to UI).
  Groups are visible in oidc token (if group scope is added to request)

{"iss":"https://yyy","sub":"xxx","aud":"zzz-harbor","exp":1564570466,"iat":1564484066,"at_hash":"zzz-w","email":"jesse.haka@xxx","email_verified":true,"groups":["group", "group2", "group3"],"name":"Jesse Haka"

• UI changes missing

At least I am trying to achieve here authentication and authorization is still handled in harbor itself. So I want basically answer to question "is this user in group called foo"

[xaleeks]

@reasonerjt
I understand. Please consider enterprise harbor admin's maintain user permission and automation perspective. I have lots of teams and over 2000 users.
I think you don't need to verify group exist in LDAP. (oidc too)
Because user who does not have the group will not pull/push that project and then user realizes that he/she does not have the group.
I guess there's no system effect.
I hope the discussion on this issue will be done as soon as possible and reviewed positively.

@Hokwang Do you have a slack so we can discuss this further, using Keycloak's specific implementation as an example to hash out this requirement. The verification of a groups existence with an identity provider as @reasonerjt explained seems unsolvable, but yea we agree the utility of adding groups trumps the risk of adding non-existent groups and creating garbage data in Harbor

[xaleeks]

We from NTT DATA also evaluate Harbor with OIDC (Keycloak). But currently we can not use it because there is no way to map Keycloak roles to Harbor groups.

The solution could be JWT as used in the OpenDistro Elasticsearch. After a login with Keycloak a JWT access token is retrieved that looks like this:

  ...
  "address": {},
  "email_verified": true,
  "roles": [
    "admin"
  ],
  "name": "Admin Admin",
  "preferred_username": "admin",
  "given_name": "Admin",
  "family_name": "Admin",
  "email": "[email protected]"
}

As you can see there is a roles there with admin as the role. This is then mapped to the internal Elasticsearch role admin.

    admin:
      readonly: true
      hash: the_hash
      roles:
        - admin
      attributes:
        attribute1: value1
        attribute2: value2
        attribute3: value3

Maybe in Harbor you could implement the same. The JWT access token could include a role and the user is then assigned to the Harbor group that matches that role.

That's an interesting idea but I don't think this is in scope for phase I at least since we are only looking for authentication for these kind of sso flows. Btw, is the above roles: admin returned Keycloak specific or standard for all OIDC identity providers

[devent]

@xaleeks The admin role is a custom client role. In Keycloak you can define custom client roles and assign them to Keycloak users. Then all roles that the user have is returned in the JWT.

[xaleeks]

a PRD (product request document) is up, feel free to make comments. We want to get this planned for engineering by end of Aug.

https://docs.google.com/document/d/1ZkYYB24Y4xBfhMlskWFimVtUnn0vRUbmK4G7H11q2x4/edit

[xaleeks]

This is WIP, looking for someone who has an auth0, Keycloak environment (or similar OIDC identity provider) to help test with Harbor, please ping me if interested.

[devent]

@xaleeks I have a private Keycloak server. I can create a realm and you can have admin rights for the realm. I use letsencrypt certificates, so SSL shouldn't be a problem.

[xaleeks]

@devent Awesome thanks for the assistance, please ping me environment details at [email protected]. We'll try to work on it next week.

[devent]

@xaleeks I have send you the Keycloak ream to your email.

[xaleeks]

Sorry, it was just brought to my attention that this doc was set to 'anyone with link can view', I have now updated it to 'anyone with link can comment'. Apologies!

[xaleeks]

We just verified against keycloak and groups claims seem to come out ok, need some fine-tuning now. Thx a lot! @devent

[xaleeks]

We are still looking to test against auth0, if anyone is using it and can work with us on some specifics, would really appreciate it!

[xaleeks]

hit a snag while verifying against auth0 , detailed here : https://community.auth0.com/t/missing-id-token-when-refreshing-token/32209. If anyone has experienced this or has workaround, let us know !

update this is resolved!

[joshatintegris]

I can volunteer to help test with OIDC via Okta. I have an Okta developer account that I'm setting up for our customers. Ideally, I'd like to be able to create a customer account in Okta and assign it to a group and have that group correspond to a group in Harbor that they get added to automatically so they can see specific private repositories.

[xaleeks]

@joshatintegris That's the scenario we're looking to test. please ping me ([email protected]) your email so we can chat further.

[stuclem]

Created https://github.com/goharbor/harbor/issues/9574 to track the doc update, so removing doc-impact from this one.

[reasonerjt]

Closing as the feature is delivered in 1.10 RC