You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
To apply Email Domain Restriction during Login with SSO #1347
Hey! I wanted to ask whether we could have a feature to apply an email domain
restriction during the SSO login step in auth.
Why is this needed in Kellnr?
We run an internal Cargo registry within our organization, and we need to
restrict authentication by email domain so that only users with an allowed
domain (e.g. @example.com) can sign in.
Proposed behaviour
A configurable list of allowed email domains (e.g. via config file or
environment variable such as KELLNR_AUTH__ALLOWED_EMAIL_DOMAINS).
After the SSO provider returns the user's profile, Kellnr checks the email
domain against that list.
If the domain is not allowed, the login is rejected with a clear error message
and no user account is created.
If the list is empty or unset, behaviour stays as it is today
My first thought is that this policy belongs in the identity provider rather than in Kellnr. Every major IdP can restrict which users are allowed to access a specific application: Entra ID has user and group assignment per enterprise app, Okta has app assignments, Authentik has policy bindings, and Keycloak has client access policies. If access to the Kellnr application is restricted there, users outside your domain never get past the SSO step, and a second check in Kellnr would never fire.
For a Kellnr-side safety net, there is also auto_provision_users = false. With that setting, an SSO login only succeeds for accounts that an admin explicitly created in Kellnr, which is even stricter than a domain allowlist.
So before I add a new configuration option, I'd like to understand your scenario better: is there something I overlook that neither the IdP-side restriction nor auto_provision_users = false covers for you? If there is a gap, I'm happy to reconsider.
The issue was that if we need to configure the IdP-side restriction that would involve applying the domain restriction across all the oAuth Clients that exists in our Credentials as Google doesn't allow you to apply restriction over a single Client and it's a project wide settings.
auto_provision_users = false covers for you
I think using this setting would cause us to manually maintain and create account for each user. If you think there are some alternatives that we can go with, I can sure look into that.
Activity
secana commentedon Sep 6, 2026
Hi @mohakco,
thank you for the feature request!
My first thought is that this policy belongs in the identity provider rather than in Kellnr. Every major IdP can restrict which users are allowed to access a specific application: Entra ID has user and group assignment per enterprise app, Okta has app assignments, Authentik has policy bindings, and Keycloak has client access policies. If access to the Kellnr application is restricted there, users outside your domain never get past the SSO step, and a second check in Kellnr would never fire.
For a Kellnr-side safety net, there is also
auto_provision_users = false. With that setting, an SSO login only succeeds for accounts that an admin explicitly created in Kellnr, which is even stricter than a domain allowlist.So before I add a new configuration option, I'd like to understand your scenario better: is there something I overlook that neither the IdP-side restriction nor
auto_provision_users = falsecovers for you? If there is a gap, I'm happy to reconsider.mohakco commentedon Sep 7, 2026
Hi @secana ,
Thank you for reaching out!
In our org we are using Google's Oauth client ID based credentials through GCP:
https://developers.google.com/workspace/guides/create-credentials#oauth-client-id
The issue was that if we need to configure the IdP-side restriction that would involve applying the domain restriction across all the oAuth Clients that exists in our Credentials as Google doesn't allow you to apply restriction over a single Client and it's a project wide settings.
I think using this setting would cause us to manually maintain and create account for each user. If you think there are some alternatives that we can go with, I can sure look into that.