Make use of roles when using OIDC

[luketainton]

• Gitea version (or commit ref): 1.10.3
• Git version: N/A
• Operating system: Linux (Docker)
• Database:
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant

Description

We use Keycloak as our SSO system and Gitea uses this via OAuth2 (OIDC) to authenticate users. We have roles (admin/user) set up on Keycloak that are assigned to users. Is there a way to have Gitea assign admin rights to users if they have the 'admin' role?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[Breee]

We would need such a feature as well.

gitea/routers/user/auth_openid.go

Line 320 in 76053ac

func RegisterOpenID(ctx *context.Context) {

Here I see that username and password is extracted.

We are using Keycloak and our use case is the following:

We have Organisations and Teams.
If a new user registers using OIDC, we want to assign him one or more Organizations and one or more Teams.

Do you think that is possible?

[marcpopp]

Ẃe could use this feature, too.

[lunny]

We need a uniform authorization synchronize mechanism for LDAP, OIDC or others.

[Morriz]

Harbor has it out of the box. You just provide it the name of the admin group in the OIDC groups claim for admins to be recognized. Teams can be given an OIDC group as well, so that incoming OIDC users can later be mapped.

I don't believe they "sync" users but map them from their OIDC connector, so their db is empty of users.

[Jamesits]

Having a consistent, unified source of identity and permission would be very convenient when working with a large group of people. This can be implemented with 2 steps:

1. Save the roles/groups a user is in and update them (for LDAP sync, update them every few minutes; for OAuth2, update during user login)
2. Allow groups/projects in Gitea to have permission assigned to a role

I'd like to contribute a little if there is a plan from Gitea developers to implement this.

[indiketa]

We need this functionality to be able to allow login or not depending on a claim value in the access token.

In our case, we use oauth2_client account auto registration but we don't want it to happen if the access token does not have a specific claim.

I have spent some time this afternoon on a proof of concept:

To make something as flexible as possible we added two new parameters in the app.ini file:

;;
;; Allow login only if access token has the following claim.
;; If claim value config parameter is not set, the login will be
;; allowed only with the presence of the claim in the access token.
;;ALLOW_LOGIN_CLAIM_NAME =
;;
;; Allow login only if the ALLOW_LOGIN_CLAIM_NAME has this value
;; No effect if claim name is not set
;; Access token value can be a single string or an array
;;ALLOW_LOGIN_CLAIM_VALUE =

Do you think is it worth doing this way?
indiketa@bd8fe3f
indiketa@f700084
indiketa@4e18d0f

[zeripath]

Hmm... OK... I'm finally in the right place to look at this stuff.

I think it's better to use the response that comes back from the provider - not the token - this is what Harbor does.

I also think it's better to add the configuration to the UI instead of using the config file.

My working tree is at:

https://github.com/zeripath/gitea/tree/oidc-claims

(this is based on 1.16)

[zeripath]

Harbor has it out of the box. You just provide it the name of the admin group in the OIDC groups claim for admins to be recognized. Teams can be given an OIDC group as well, so that incoming OIDC users can later be mapped.

I don't believe they "sync" users but map them from their OIDC connector, so their db is empty of users.

I don't think there is anyway we can get around having a db of users and the management that entails.

If we had no db - we'd have no way of sending/storing notifications via email or on the UI, no ssh logins, no way of listing who can be '@'d and no gpg keys. (unless of course you assert LDAP only.)

[Morriz]

Couldn’t a user be recognized via oidc first and then a routine automatically creates a record in the db?

[zeripath]

Yes and we do a part of that already - my comment was simply that we cannot get away without a DB.

However if we want to extend what we take from OIDC we need to think about what happens when they log-in again.

---

To manage LDAP providing SSH keys we now mark them with the loginsource associated with the key. This could be extendable to OAuth/OIDC providing SSH keys in the same way.

---

For site administrator & restricted statuses: LDAP simply overrides and rewrites the statuses. I guess this is fine to replicate on the OAuth/OIDC equivalent.

---

User visibility is not currently managed by LDAP. I suspect that this could simply be overridden by OIDC/OAuth/LDAP but I'm not sure that's the best thing to do - it really could need more thought.

---

However, this is avoiding what is really wanted:

Organization membership, team membership, & repository collaboration

For this to be providable by OAuth/OIDC/LDAP we would need to mark the membership with the loginsource that provided that membership. This is probably doable - but is involved.

In terms of the external configuration: I envision this could be done with two or three fields in OIDC/OAuth. Let's say OrganizationClaimName & CollaborationClaimName (Actually - this could all just be done with a single GroupClaimName and would fit with harbor)

• The contents of the OrganizationClaim would be a comma-separated list of Organization names and Organization:Team name pairs. You could split this in two.
• The contents of the CollaborationClaim would be a comma-separated list of Owner/Repo:Perm triples.
• LDAP could actually provide information about the team/repo mappings but I'm not sure how OAuth/OIDC could do that.

Another option would be to add Roles as an orthogonal user class.

[netcicd]

I get from the documentation that it is going to be GroupClaimName, but I also see required-claim-name, required-claim-value, admin-group and restricted-group.

Can you provide an example of a working JWT, so I can build it in Keycloak?

[Morriz]

The above PR is not delivering what is suggested. Seeing that GroupClaimName was chosen, it is expected to map correctly to team names, however it does not do so.

In fact, the only thing made to work in that PR is the adminGroup setting.

@zeripath was something left out of that PR? Can it be revived to fix that missing part?

[jaredpatrick37]

Is this still WIP?

I am testing out OIDC using the --admin-group flag with the cli but I am not sure if it is actually implemented at this point.

[kdumontnu]

With #19555 merged, should we change the title here to: "Allow mapping user to admin role with OIDC"?

[n3vu0r]

Admin group membership can already be mapped from an IdP like Keycloak. It seems to work only with flat token claim names, meaning a nested token name like resource_access.${client_id}.roles, which is the default in Keycloak, does not work. But under Client scopes -> roles -> Mappers -> client roles changing Token Claim Name from resource_access.${client_id}.roles to something flat like ${client_id}_groups does work.

In Gitea then set the following two fields (assuming client ID is gitea and admin role name is admin):

Claim name providing group names for this source (Optional) = gitea_groups
Group Claim value for administrator users. (Optional - requires claim name above) = admin

[codesalatdev]

It seems to work only with flat token claim names, meaning a nested token name like resource_access.${client_id}.roles, which is the default in Keycloak, does not work.

Thanks for that! Also: the claim must be included in the ID Token, not only in Authorization Token

[xinnj]

I follows these steps and it works for me.

On Keycloak:

1. Create a realm role, like "gitea_admin"
2. Assign the role to the user
3. Create a client with authentication enabled
4. On client's "client scopes" tab, click client dedicated scopes
5. Add a predefined mapper named "groups" (maybe located on the second page)

On Gitea, config the authentication source like this: