Default config changes

[infogulch]

Cool. What do you think about item 2?

[girish]

@infogulch I think disabling the signin form disables admin login as well. We won't put it in the package since then the first login won't work (to change admin password) . But I think it makes sense in general.

[infogulch]

Yes that's what I'm saying: I've never logged in with the root user since changing the password, I've always managed my gitea instance by giving my cloudron identity administrator privileges in the app. So maybe the admin is not even necessary. And if we just completely disable the admin login this would simplify first-time setup of the gitea app.

[girish]

Doesn't the first OIDC user need to be made an admin by logging in as admin first?

[infogulch]

What if the OIDC user can be made admin through the CLI in start.sh?

[girish]

Users are auto-created by gitea on OIDC login. So, we may not have the user object in gitea database in start.sh time.

[infogulch]

Yes I suspected that's how it would work.

What if we configure Gitea admin group claims from OIDC tokens? Can cloudron add a claim to the token when the authenticated user is an operator?

• --group-claim-name: Claim name providing group names for this source. (Optional)
• --admin-group: Group Claim value for administrator users. (Optional)

-Gitea Command Line Reference

https://github.com/search?q=repo%3Ago-gitea%2Fgitea oauth2_group_claim_name&type=code
https://github.com/search?q=repo%3Ago-gitea%2Fgitea+oauth2groupclaimname&type=code
https://github.com/search?q=repo%3Ago-gitea%2Fgitea GroupClaimName&type=code

Ok it looks like these configs are not settable by app.ini. I'll ask in the discord and post back here.

https://github.com/go-gitea/gitea/blob/b861d86f80ea7a848efb539b798bbde3c7877d02/modules/setting/oauth2.go#L63-L79

[infogulch]

Ok I found that the configuration is loaded from the login_soruce table, which has a JSON column cfg with OAuth2-specific fields. For reference it works like this:

• OAuth2 login starts in SignInOAuthCallback
  • This calls GetActiveOAuth2SourceByAuthName to get the OAuth config
  • GetActiveOAuth2SourceByAuthName loads the login configuration from the database
  • This populates a models.auth.Source struct from the login_source table
  • The Cfg field is parsed into the source-specific struct services.auth.source.oauth2.Source which contains the GroupClaimName and AdminGroup fields.
• Then SignInOAuthCallback calls function getUserAdminAndRestrictedFromGroupClaims to read these fields to get the user's admin status from the oauth claims.

I looked at my login_source table:

SELECT * FROM login_source WHERE type = 6 /*OAuth2*/ AND name = 'cloudron' AND is_active = 1;

+----+------+----------+-----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------+--------------+-----------+-------------------+
| id | type | name     | is_sync_enabled | cfg                                                                                                                                                                                                                                                                                                                                                                                                          | created_unix | updated_unix | is_active | two_factor_policy |
+----+------+----------+-----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------+--------------+-----------+-------------------+
|  1 |    6 | cloudron |               0 | {"Provider":"openidConnect","ClientID":"<snip>","ClientSecret":"<snip>","OpenIDConnectAutoDiscoveryURL":"https://my.<cloudron domain>/openid/.well-known/openid-configuration","CustomURLMapping":null,"IconURL":"","Scopes":["openid email profile"],"RequiredClaimName":"","RequiredClaimValue":"","GroupClaimName":"","AdminGroup":"","GroupTeamMap":"","GroupTeamMapRemoval":false,"RestrictedGroup":""} |   1752293846 |   1752293846 |         1 |                   |
+----+------+----------+-----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------+--------------+-----------+-------------------+

Here you can see the JSON fields GroupClaimName and AdminGroup in the cfg column.

So these configuration settings can be updated today with a query like this:

UPDATE login_source
SET cfg = JSON_SET(cfg, '$.GroupClaimName', '<group claim name>', '$.AdminGroup', '<operators group name>')
WHERE type = 6 /*OAuth2*/ AND name = 'cloudron' AND is_active = 1;

Obviously it would be better if this setting was exposed in app.ini, but this is enough for testing. And we'll have a stronger case for a PR to add this if we come with a live use-case.

To me it seems like the next steps are:

1. Figure out if Cloudron even exposes the group names and the app's operators group via OAuth2 claims
2. Test to see if filling in the GroupClaimName and AdminGroup fields in the UI works
3. Test to see if changing it by sql works
4. Decide if this makes sense as a default
5. Update the app to use it by default
   a. start.sh can open a subshell that tries to update these settings by direct query, checking in a loop every 5 seconds waiting for the schema to populate on first boot and for the login_source row to be created from config.
   b. Add the settings ENABLE_PASSWORD_SIGNIN_FORM = false and ENABLE_BASIC_AUTHENTICATION = false, and remove the first-time setup task to change the root password.
   c. Open an issue with Gitea to expose these settings via app.ini, remove the subshell workaround and use the exposed config options when they are available.

[infogulch]

@girish So my question for you is: Does cloudron assign an oauth2 claim for groups, specifically for app operators? If not, could it?

[nebulon]

Cloudron will return the groups a user is part of. However admin or app operator are roles not groups. So an app does not know if a user is also an admin on your Cloudron or such.

Long ago we did expose this, but this usually does not map well to apps. Roles and groups often mean different things within different apps.

[infogulch]

I see. Having some impedance mismatch between cloudron roles and app groups makes sense.

What if cloudron exposed a separate "roles" claim in addition to groups? Gitea could be configured to use the cloudron role claim as Claim name providing groups for this source, then set administrator as the Group Claim value for administrator users. Or set it to operators if you want to allow every operator to act as a Gitea Site Administrator.

In this case as long as Map claimed groups to Organization teams is left blank then there's no mapping that will confuse the app.

[nebulon]

This is currently not on our list. But you should be able to use Cloudron groups for that already, just have to add the users accordingly.

[infogulch]

What I was aiming for with this was to simplify the Gitea app install process for new instances. This would:

1. Remove the step where new app owners must change the root password and save it, eliminating the initial period where new installs are vulnerable to spam and abuse, and eliminating the need for a root user at all.
2. Allow for disabling username/password entry form, streamlining cloudron logins.
3. Derive Gitea Site Administrator privileges directly from app owner/operator role, simplifying app administrator delegation.

These goals are related to the default initial configuration of the gitea app, and are thus not possible to achieve with cloudron groups.

To do this, cloudron would need to:

1. Add a role claim (maybe roles plural) to the claims returned by getClaims, corresponding to the user's role assignment for that app.
2. Accept a PR to the gitea app that configures it to use these claims to set the site administrator role, after waiting for gitea to implement the ability to configure these settings from app.ini.

I understand if you are not interested at this time.