Single sign-on for applications with ns8-idp #8258

Users of a NethServer 8 cluster sign in to each application separately, typing the same password several times a day. Many community members and partners asked for single sign-on (SSO), often to sign in with an existing cloud account such as Microsoft Entra ID (formerly Azure AD) or Google. Single sign-on also makes two-factor authentication (2FA) available to every application at once: it is enabled and enforced in one place, the identity provider, instead of in each application, where it is often missing.

The developer documentation now describes how an OpenID Connect (OIDC) provider plugs into NS8, and the new ns8-idp application is its reference implementation, currently in alpha and based on Keycloak. The purpose of this issue is to bring ns8-idp to a stable release and to track the integration of the most requested applications.

Proposed solution

• Decide the identity provider software of ns8-idp among Keycloak, Authentik and Zitadel, considering features (OIDC, federation, 2FA, LDAP user sync), maintenance and security record, and resource footprint (memory, CPU, disk), as many clusters run on small nodes.
• Release ns8-idp as a stable application: one sign-in realm for each user domain, with users and groups taken from the domain's LDAP database.
• Applications ask ns8-idp for an OIDC client with the register-client action, as described in the developer manual. The client is removed when the application is removed or unbound from the user domain.
• Optionally, a realm accepts only logins through a federated provider, like Microsoft Entra ID.
• Integrate these applications, each one tracked by its own issue:
  • Nextcloud: Nextcloud: sign in with ns8-idp #8262
  • Roundcube: Roundcube: sign in with ns8-idp #8263
  • Mail (sign-in tokens for webmail clients): Mail: accept ns8-idp tokens for IMAP and SMTP #8264
  • NethVoice: NethVoice: sign in with ns8-idp #8265
  • WebTop: WebTop: sign in with ns8-idp #8266
• Applications keep working with LDAP passwords when SSO is not configured. SSO is an option, not a replacement: the administrator decides, for each application, whether to use the available provider.

Alternative solutions

• Each application connects directly to the cloud provider (Microsoft Entra ID, Google): every application needs its own client registration in the cloud provider, and its own 2FA policy. A central NS8 identity provider eases the cloud federation: one client in the cloud provider for the whole cluster, instead of one for each application.
• A core-provided identity broker: discarded by the architecture design, which keeps the core minimal and leaves the provider to an application.
• SAML2 for every application, like NethVoice already supports: OIDC is better supported by the target applications and simpler to configure.

Additional context

When a realm accepts only federated logins, an application with its own login form should send its users straight to the provider, and document an emergency login path for when the provider is down. Protocols outside the browser, like IMAP and WebDAV, keep using LDAP passwords.

See also

• Architecture design: Define core SSO architecture for external identity providers #8080
• NethVoice SAML2 SSO: NethVoice: pluggable authentication methods with SAML2 Single Sign-On #8142
• Developer manual, Single sign-on: https://nethserver.github.io/ns8-core/core/user_domains/#single-sign-on
• ns8-idp: https://github.com/NethServer/ns8-idp
• Community requests: https://community.nethserver.org/search?expanded=true&q=SSO%20%23feature
• https://community.nethserver.org/t/nethserver-project-milestone-8-8/27054/7?u=davidep
• https://partner.nethesis.it/t/azure-active-directory/9952
• Discussion https://mattermost.nethesis.it/nethesis/pl/d1csx57jftrpiq9494ibajf4ao