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

Pre-Installation
Create Normal and WildCard DNS record like
auth.domain.tld
*.auth.domain.tld

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

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

image

After Installation, configure Zitadel, and Access your domain

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

IF correct Should take you to Password Page
image

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
image

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

Configuration for Zitadel

In Zitadel, go to Instance > Settings for instance-wide LDAP setup or <Organization Name> > Settings for organization-wide LDAP setup.

Identity Providers Setup

Click Identity Providers and select Active Directory/LDAP.

Group filter is not supported in Zitadel at the time of writing.

Replace every instance of dc=example,dc=com with your configured domain.

Connection

  • Name: The name to identify your identity provider
  • Servers: ldaps://<FQDN or Host IP>:<Port for LADPS> or ldap://<FQDN or Host IP>:<Port for LADP>
  • BaseDn: dc=example,dc=com
  • BindDn: cn=admin,ou=people,dc=example,dc=com. It is recommended that you create a separate user account (e.g, bind_user) instead of admin for sharing Bind credentials with other services. The bind_user should be a member of the lldap_strict_readonly group to limit access to your LDAP configuration in LLDAP.
  • Bind Password: <user password>

User binding

  • Userbase: dn
  • User filters: uid. mail will not work.
  • User Object Classes: person

LDAP Attributes

  • ID attribute: uid
  • displayName attribute: cn
  • Email attribute: mail
  • Given name attribute: givenName
  • Family name attribute: lastName
  • Preferred username attribute: uid

optional

The following section applied to Zitadel only, nothing will change on LLDAP side.

  • Account creation allowed
  • Account linking allowed

Either one of them or both of them must be enabled

DO NOT enable Automatic update if you haven’t setup a smtp server. Zitadel will update account’s email and sent a verification code to verify the address.
If you don’t have a smtp server setup correctly and the email adress of ZITADEL Admin is changed, you are permanently locked out.

Automatic creation can automatically create a new account without user interaction when Given name attribute, Family name attribute, Email attribute, and Preferred username attribute are presented.

Enable Identity Provider

After clicking Save, you will be redirected to Identity Providers page.

Enable the LDAP by hovering onto the item and clicking the checkmark (set as available)

Enable LDAP Login

Under Settings, select Login Behavior and Security

Under Advanced, enable External IDP allowed

Thank you for testing in Advance.

4 Likes

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

--network=slirp4netns:allow_host_loopback=true
--network=host

and
correlation with

--add-host=accountprovider:10.0.2.2

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.

2 Likes

While Playing Around with the Ldap Service from NS8.

the Following Attributes seemed to have worked for me.




Login with any of the SUers in ns8, promts me to create the user in Zitadel

since i have deifned above to do that.

I have Updated the PAramters Above here:

Also HAppy to Announce that after very thorough internal Testing, Zitadel has Reached Beta Stage, with BEta 1 pre-released

Update: Zitadel now RUns Version 2.58.0 whcihc implements V2 Zitadel API in prod.

HEllo @danb35, I am curious about something in relation to this specific Question.
Is this a situation that only affects NExtcloud, or are any other applications affected by this?

I have update with notes for linking LDap into Zitadel as well. Above.

Nextcloud is the only application I’ve seen it with, but it’s also the only Nethserver application I was able to use with Authentik–I never did get any of the webmail apps to work that way.

i generally dont think Making use of SSO for webmailApps of NS8 is a great idea, Maybe to just leave it at Ldap level.

If you have a moment, you could kindly help us test Zitadel with Nextcloud, together with the Pre-implemented Ldap on NS8. if we still face the same issue. Good thing NS8 allows setting up Nextcloud without Ldap.

challenge is the migration of users from LDap based to SSO based.

Equallly, i’d be curious t test a scenario where, SAML users from LLNG, as tested with SAML users from Authentik, as well as SAML users from zitadel. All having the same Ldap Backend.

if the SAML users retain the same user, then migration will be more easier, otherwise, alot more headache.

I think this thought bypasses the whole idea behind IAM (Identity and Access Management) Please note the 2 seprate areas being “Identity” and “Access”. A well though out IAM plan and usage of tools (such as Authentic, and Zitadel) covers both grounds, “Who can access what when and from where”.

A good IAM tool will sync periodically with entity sources such as LDAP and AD and the rest of the logic is being crafted within the IAM tool, including authentication, so not directly or interactive with LDAp or AD, but a synced version. IAM is ,opposed to popular believe, not only for large enterprises for any date is precious.

SSO is only one aspect, derived from a well implemented IAM tool, and should be a “confined and closed circuit” thus NOT making/creating exceptions for various apps/resources.

I believe the focus is too much on SSO whilst IAM should be the topic where SSO is a part of.

Just saying.

I think if we base it on what you have defined Above, it covers ground on exactly that issue.

YEs ad/Ldap, could be a Directory, while an IAM tool is implemented for access management.

I saw a certain discussion somewhere here

where someone is trying to impelment public and internal apps, with internal and external users, each with different access designs.

i think this kind of IDP architecture can only be acheived via an IAM, and Direct AD.Ldap can not acheive this

IAM is Identity and Access, not just access, for acces can only be granted to en entity when the identity is verified. Then the authentication part kicks to authenticate the entity for the requested resource.

Depending of the capability of the resource/app ACL’s can be invoked by the IAM tool to determine the level of access and internal rights.