🚀 Feature: Restrict Signups to specified mail domains

[TadeSF]

🔖 Feature description

As an administrator for my organization, I want to be able to restrict who is able to log in to a few (mail) domains that are associated with our organization. An added field to the global admin configuration to list these domains is needed for that.

Btw: We love using pingvin-share! It has made not only our GDPR compliance but also everything else with an organization wide sharing tool so much easier.

🎤 Pitch

Currently, I am restricting the access to who is able to sign in or sign up by using a oauth plugin for our reverse proxy that forbids access for mail addresses not in our organization realm. Since you recently added the option to sign in with openID connect, this has become a totally unnecessary step, since it would be very easy to just forbid access for everyone but users with an organization mail address.

The reverse proxy setup is also unnecessary complex since I want to restrict access to registration, log in and file share, but not to actually viewing and downloading of the files, which should remain open for "outsiders".

Inviting every user manually is also not an option since 1) i want the registration flow to be as simple as possible and 2) at our non-profits scale I am simply not able to respond in a timely manner to registration requests.

[COMPLEXWASTAKEN]

hello are you talking about something like this

[stonith404]

@TadeSF The restriction should only be for authentication with OAuth2, right? Because it wouldn't make sense for email and password authentication as the email doesn't get validated.

[TadeSF]

I mean the concept itself does apply to all means of authentication. But I agree that it wouldn't really make sense to implement it if there is no way to check if somebody actually has access to the email.

For me and my use case, applying this to OICD only would be sufficiant since I disabled email signup anyways - but I guess others using pingvinshare without OICD Issuer infrastructure in the background might still be interested in that feauter?

Also maybe implementing an email verification flow is generally worth a thought? 😊
Buth thats a different issue ofcourse and I can't tell what the cons/implications might be.

[COMPLEXWASTAKEN]

@TadeSF The restriction should only be for authentication with OAuth2, right? Because it wouldn't make sense for email and password authentication as the email doesn't get validated.

i put this in my pull request and i didnt mean to sorry

[stonith404]

@TadeSF I think email verification is out of scope for this project. In my opinion it makes more sense to use a OIDC provider like Keycloak if advanced authentication features are required.

What OIDC provider do you use if I may ask?

[TadeSF]

Yeah, i think thats fair.

Internally, we are using google workspaces and currently use google as our OIDC Issuer. But we are currently in a transition process switching to Zitadel.

We are currently renewing our services and in order to avoid dealing with authentication all that much, we want to allow our users outside the organization to have one central Account and use OICD for all means of authentication. And to make privacy matters easy, we therefore decided on a selfhosted solution. Thats where Zitadel comes into play 😊

[stonith404]

@TadeSF Thanks for sharing. Isn't there a way to limit the accounts for an OIDC client on Google's side? For example Microsoft Entra ID allows you to specify which tenants are allowed to sign in.