Contributions from ConsortiumGARR fork: new settings, hide login and CI pipeline

[rizlas]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Feature request

Which Nextcloud Version are you currently using: 33.0.0

Is your feature request related to a problem? Please describe.

We've been maintaining a fork of user_oidc with several additions to cover use cases we needed in production. Before investing time in cleaning up the code for a proper PR, we'd like to know if you'd be interested in accepting contributions in these areas.

Describe the solution you'd like

The full implementation is available in our fork at ConsortiumGARR/user_oidc. Here is a summary of what we've added:

---

CI pipeline with krankerl

Automated build and packaging pipeline using krankerl via krankerl-builder. The pipeline also includes automatic GitHub release creation, with the krankerl build attached as a release asset.

---

Hide default Nextcloud login

Reworked approach to hide the native Nextcloud login form using IAlternativeLogin, as suggested in the existing comment at Application.php#L125. The behavior is toggleable from admin settings. The approach is inspired by nextcloud-social-login.

---

New provider settings

Setting	Description
new-users-require-approval	Require administrator approval (enable them) for new users after first login
group-forbid-login-without-group	Forbid login for users not member of any group provided by the OIDC group claim
mapping-group-admin-for	Attribute mapping for subadmin group provisioning
appearance-icon	Custom login button icon in base64 format
appearance-button-background-color	Custom login button background color

---

Additional context

(screenshots attached for the hide default login feature)

or /login#body-login

[julien-nc]

Wow I was not aware that such a nice fork was existing. Thank you for offering to upstream the nice changes you made!

Let me take them one by one:

1. CI pipeline with krankerl: I think we are fine with the current build and packaging flow. It's not perfect but it is done this way across many apps all around in Nextcloud. I think we will keep that unchanged for consistency sake. At least for now.

Can you still explain what justified those changes on your side? Here is the flow on our side:

• Make a release PR (bump version number and update CHANGELOG.md)
• Once it's merged, tag the merge commit with a version number
• Push this tag to the code repo (this one) and to the "release" repo in the nextcloud-releases org
• The release action is triggered, it builds the release pkg and creates the release in our appstore

2. Hide default Nextcloud login: Why do you keep it possible to toggle back to the old login registration method? Any issue/limitation with IAlternativeLogin?
   I'm very much in favour of this change.

3. New provider settings: All those new features are interesting. If they don't make the backend code more difficult to read, let's go.
   I have some doubts about new-users-require-approval. What's the use case for it? I always assumed that could be handled on the IdP side by restricting the users that can login with a specific Oidc client. Or even with the group whitelist feature of user_oidc. Any reason why a manual action from a NC admin is necessary?

We have to discuss that internally and i'll come back to you soon to discuss how and when we can proceed.
Thanks again

[julien-nc]

Hey,

Could you give more details on mapping-group-admin-for ? Not sure I get exactly what it does.

Let's move forward with the upstream.

What we don't want right now

• CI pipeline with Krankerl: Not sure it makes sense to change out current release process
• New provider settings
  • new-users-require-approval: Not sure we want that for now. Let's discuss the use cases. We can always include that later

The ones that can get in

• IAlternativeLogin
  • Hide default login
  • Migrate to IAlternativeLogin for all configured providers
• New provider settings
  • group-forbid-login-without-group
  • appearance-icon and appearance-button-background-color

Can you make atomic PRs?
I'll make sure we review those PRs in a relatively short time 😁 .

Thanks again for offering to upstream and starting a discussion before making all the PRs.

[rizlas]

Hi, sorry for the late answer but I was pretty busy during the last week.

Here some insights about what you asked:

mapping-group-admin-for

This is simply the mirror of the existing groups mapping setting. While groups mapping controls which groups a user belongs to (based on an OIDC claim), mapping-group-admin-for controls which groups the user is a subadmin of. Same logic, different privilege level.

Example of the UI:

---

new-users-require-approval

We operate in a complex federated authentication environment where authorization logic is not always easy to enforce at the IdP level. In our case, users are synchronized from an external IdP into our Keycloak instance, and implementing fine-grained access control for this specific use case at the Keycloak level would require significant additional complexity on our side.

To make this more concrete: consider a scenario where a group of users from an organization (e.g. university.edu) is entitled to use Nextcloud, and a local group admin manages that organization's users. All members of university.edu can
successfully authenticate via OIDC, but only a subset of them should actually be granted access to the service. Disabling new users on first login gives the Nextcloud admin (and the group admin) the ability to explicitly activate only the users who should have access, acting as a manual onboarding gate when IdP-side restrictions are not feasible.

---

IAlternativeLogin / toggleable hide

The toggle gives the Nextcloud admin flexibility over how the login page appears. When enabled, the native login form is hidden and replaced by the OIDC button(s), with a fallback button for emergency admin access. When disabled, the native login remains fully visible alongside the OIDC buttons.

Example:

Toogle on

Screencast.from.2026-03-27.17-01-21.webm

Toogle off

---

CI / Krankerl

This was mainly a convenience for our internal workflow and our deploy setup. It makes total sense to keep consistency with your release process.

---

Atomic PRs

Will do! I'll open separate PRs for each feature.

I'll test all this settings again one by one and coming back with individual PR when ready.

Thanks