Zitadel SSO: Multi tenant Identity Infrastructure

Single SignOn Has been a sticky Discussion in these forums: Search results for 'SSO #feature' - NethServer Community

We are Happy to Present Zitadel SSO is Now Nethserver App;

An Alternative to Authentik Equally Robust, But completely Free and OSS. No premium versions

Zitadel Can Infinitely Scale with CockroachDB

However Our Setup Uses PgSQL, which i felt was a Simpler Option for NS8 Clusters and Users

Create Normal and WildCard DNS record like

Zitadel Is Multi Tenant By Design, for SaaS B2B Cases thus, for each New Organization Created, we tend to have orgName.zitadel.domain.tld

Install our Repo through https://forge.genius.ke/
Once Installed and Enabled, locate Zitadel from the UI


After Installation, configure Zitadel, and Access your domain

Default Login Details
USERNAME: zitadel-admin@zitadel.fqdn
PWD: Password1!

IF correct Should take you to Password Page

Skip or Setup 2FA

After changing Default Password, you should be able to see your dashboard

Locate Zitadel Http Routes in settings

Create Wildcard http Routes, Defind by your Wildcard Domain defined for zitadel

IN my Tests it was impossble to define a wildcard route

SO i defined the First Available orgName

Above is meant to deal with External ZITADEL Access | ZITADEL Docs

However i still need to figure out the setup for

If you run ZITADEL behind a reverse proxy, you need to ensure that it sends the correct request headers to ZITADEL. The proxy must either ensure that

  • the original Host header value is assigned to the Forwarded headers host directive.
  • the original requests Host header value is unchanged by the proxy.

Zitadel Configs with Traefik are here: Configure ZITADEL with Traefik | ZITADEL Docs

Tested Apps with Ready Tutorials

Nextcloud is support here: Use ZITADEL as SSO provider for self-hosting

Thank you for testing in Advance.


Great, many thanks! :clap:

It seems that the Zitadel app is only available in the test repo.

that is correct, Alot of tests needs to be done first, for it to migrate to production repo. its on the repo for convenience of installing, and upgrading

1 Like

How does it work with existing users? That is, if a user has logged into Nextcloud using the NS8 account provider (LDAP or AD), and then logs in using Zitadel, will the user see the same data? I don’t believe we were ever able to make this work properly with Authentik.

Was this also not an issue with LemonLdap as well.

TBH i am yet to test this, but it is also one of the key things i wish to know as well.
I have submitted i to the community so that you can help me test the quarks as we fix whatever challenges arise with its use.

My first Order is to Have an SSO implementation that can help me replace LLNG for NS8, without significant lose in workflow. help me check how LLNG handles things.

We’re working on quite a number of WOnderful NS8 Apps, and Testing is one of the toughest tasks for us.

I pray its not too much trouble, you help us test the complex parts, What you find out, we Fix.

We also Hope to internal Use Zitadel for our SaaS solution, Under development, since it offers multi-tenant architecture. so if we can make it solid, the better for everyone.

Yes, and I wasn’t able to resolve it with LLNG either.

1 Like

with the Amount of Customizations that Zitadel Offers on their solution, and Direct API for managing functions i think we could put in the Effort to Make this as Seamless as possible…

WOuld be expensive… well atleast for me, but worthwhile.

RIght now help me test if Connection with Ldap works, so i can make necessary adjustments, then you test again…

@davidep am trying to understand something.
Whats the difference between these


correlation with


i seem to notice, some official module use the first one, others the second one, and the third one available in some and not in others…

They choose the network namespace of the container: private vs host. I’d choose private for better isolation, e.g. if the application runs some private services like a DB. Host may be a better choice for performance, but has more security implications.

If the container has the allow_host_loopback=true option, the add-host make sense, otherwise not.