Nextcloud Single Sign-on (SSO) er­mög­licht die zentrale Be­nut­zer­au­then­ti­fi­zie­rung über einen Identity Provider (IdP), sodass Nut­ze­rin­nen und Nutzer sich nur einmal anmelden müssen. Tech­no­lo­gien wie SAML 2.0, OpenID Connect und LDAP bzw. Microsoft Active Directory verbinden Nextcloud mit zentralen Be­nut­zer­ver­zeich­nis­sen und erhöhen Si­cher­heit, Be­nut­zer­kom­fort sowie die Kon­sis­tenz von Zu­griffs­rech­ten.

LDAP- und Active-Directory-Anbindung

Die Grundlage vieler zentraler Au­then­ti­fi­zie­rungs­um­ge­bun­gen ist ein Ver­zeich­nis­dienst wie LDAP oder Active Directory. In Nextcloud erfolgt die In­te­gra­ti­on über die App „LDAP user and group backend“, die in der Ad­mi­nis­tra­ti­ons­ober­flä­che aktiviert wird. Nach der Ak­ti­vie­rung kann die Ver­bin­dung zum LDAP- oder AD-Server direkt im Bereich „LDAP/AD-In­te­gra­ti­on“ kon­fi­gu­riert werden.

  1. Zunächst müssen die Server-Adresse, der Port sowie das Ver­schlüs­se­lungs­ver­fah­ren definiert werden. Für pro­duk­ti­ve Um­ge­bun­gen sollte aus­schließ­lich LDAPS (Port: 636) oder STARTTLS (Port: 389) verwendet werden, damit Zu­gangs­da­ten und Ver­zeich­nis­ab­fra­gen ver­schlüs­selt über­tra­gen werden. Zu­sätz­lich wird ein so­ge­nann­ter Bind-User hin­ter­legt, über den Nextcloud Such­an­fra­gen gegen den Ver­zeich­nis­dienst ausführt.
  2. An­schlie­ßend erfolgt die De­fi­ni­ti­on der Benutzer- und Grup­pen­ba­sis. Dabei wird fest­ge­legt, in welchen LDAP-Con­tai­nern oder OU-Struk­tu­ren nach Nut­zer­kon­ten gesucht werden soll. Über LDAP-Filter lassen sich gezielt nur bestimmte Be­nut­zer­grup­pen im­por­tie­ren, bei­spiels­wei­se Mit­ar­bei­ten­de einer be­stimm­ten Abteilung oder externe Pro­jekt­kon­ten.

Ein zentraler Kon­fi­gu­ra­ti­ons­punkt ist das Attribut-Mapping. Nextcloud benötigt eine stabile und ein­deu­ti­ge Kennung für jedes Be­nut­zer­kon­to. In Microsoft-Active-Directory-Um­ge­bun­gen wird dafür ty­pi­scher­wei­se objectGUID verwendet, in OpenLDAP häufig entryUUID. Attribute wie uid eignen sich nur dann als Iden­ti­fi­ka­tor, wenn sie dauerhaft stabil und eindeutig bleiben. Die UUID-Zuordnung ver­hin­dert doppelte Accounts und stellt sicher, dass Be­nut­ze­rin­nen und Benutzer auch nach Na­mens­än­de­run­gen eindeutig iden­ti­fi­ziert werden.

Zu­sätz­lich können Grup­pen­at­tri­bu­te syn­chro­ni­siert werden. Dadurch lassen sich Nextcloud-Gruppen au­to­ma­tisch aus LDAP- oder AD-Gruppen ableiten. Rollen und Be­rech­ti­gun­gen bleiben damit zentral steuerbar und müssen nicht separat in Nextcloud gepflegt werden. Die LDAP-Anbindung dient primär der Benutzer- und Grup­pen­ver­wal­tung. Die ei­gent­li­che Single-Sign-on-Anmeldung erfolgt dagegen meist über SAML oder OpenID Connect, die auf denselben Ver­zeich­nis­da­ten aufbauen können.

Nextcloud Workspace
Die souveräne Kol­la­bo­ra­ti­ons-Plattform für Ihr Un­ter­neh­men
  • Voll­stän­di­ge Da­ten­sou­ve­rä­ni­tät in deutschen Re­chen­zen­tren
  • Sicheres Teamwork mit E-Mail, Office, Chat und KI
  • Einfache Anwendung & volle Ska­lier­bar­keit

Wie funk­tio­niert die SAML-2.0-In­te­gra­ti­on in Nextcloud?

SAML 2.0 gilt in vielen Un­ter­neh­men als Standard für web­ba­sier­tes Single-Sign-on. In Nextcloud wird SAML über die App „SSO & SAML au­then­ti­ca­ti­on“ in­te­griert. Die App wird mit Nextcloud aus­ge­lie­fert, ist jedoch stan­dard­mä­ßig de­ak­ti­viert und muss zunächst auf der Apps-Seite aktiviert werden. Danach steht die Kon­fi­gu­ra­ti­on im Ad­mi­nis­tra­ti­ons­be­reich unter „SSO & SAML au­then­ti­ca­ti­on“ zur Verfügung.

Nextcloud fungiert in diesem Fall als Service Provider (SP), während ein externer Identity Provider wie Keycloak oder Authentik die ei­gent­li­che Be­nut­zer­an­mel­dung übernimmt. Nach der Ak­ti­vie­rung der App müssen Metadaten zwischen beiden Systemen aus­ge­tauscht werden. Der Identity Provider benötigt die Service-Provider-Metadaten von Nextcloud, darunter die Assertion Consumer Service URL (ACS-URL) und die Entity-ID. Umgekehrt im­por­tiert Nextcloud die Metadaten des Identity Providers, ins­be­son­de­re das Si­gna­tur­zer­ti­fi­kat und die Login-Endpunkte. Die Au­then­ti­fi­zie­rung läuft an­schlie­ßend über signierte SAML-As­ser­ti­ons ab. Meldet sich ein User an, leitet Nextcloud den Browser an den Identity Provider weiter. Nach er­folg­rei­cher Anmeldung sendet der IdP eine signierte Assertion zurück, die Be­nut­zer­in­for­ma­tio­nen und Attribute enthält.

Besonders wichtig ist das Mapping der User-ID. Wird SAML gemeinsam mit einem be­stehen­den Benutzer-Backend wie LDAP oder Active Directory genutzt, muss das im SAML-Token über­mit­tel­te UID-Attribut zur internen Be­nut­zer­ken­nung in Nextcloud passen. An­dern­falls können Logins fehl­schla­gen oder doppelte Konten entstehen. Wird dagegen SAML-Auto-Pro­vi­sio­ning verwendet, legt Nextcloud Be­nut­zer­kon­ten beim ersten Login anhand des kon­fi­gu­rier­ten UID-Attributs an. Auch in diesem Fall sollte ein dauerhaft stabiles Attribut gewählt werden, da spätere Än­de­run­gen zu Zu­ord­nungs­pro­ble­men führen können.

Zu­sätz­lich können Grup­pen­at­tri­bu­te über­tra­gen werden. Dadurch lassen sich Nextcloud-Gruppen au­to­ma­tisch anhand der SAML-Assertion syn­chro­ni­sie­ren. In größeren Um­ge­bun­gen ver­ein­facht das die zentrale Rech­te­ver­wal­tung erheblich. SAML bietet um­fang­rei­che Si­cher­heits­funk­tio­nen wie XML-Si­gna­tu­ren, Zer­ti­fi­kats­va­li­die­rung und zeitlich begrenzte As­ser­ti­ons. Gleich­zei­tig ist die Kon­fi­gu­ra­ti­on häufig komplexer als bei OpenID Connect (OIDC), da bei SAML Zer­ti­fi­ka­te, Metadaten und Attribut-Mappings exakt ab­ge­stimmt werden müssen.

Compute Engine
Die ideale IaaS für Ihre Workloads
  • Kos­ten­güns­ti­ge vCPUs und leis­tungs­star­ke de­di­zier­te Cores
  • Höchste Fle­xi­bi­li­tät ohne Min­dest­ver­trags­lauf­zeit
  • Inklusive 24/7 Experten-Support

OpenID-Connect-(OIDC)-Im­ple­men­tie­rung

OpenID Connect ist eine Iden­ti­täts- und Au­then­ti­fi­zie­rungs­schicht oberhalb des OAuth-2.0-Au­to­ri­sie­rungs-Frame­works, die ins­be­son­de­re für Web­an­wen­dun­gen und APIs ent­wi­ckelt wurde. In Nextcloud erfolgt die In­te­gra­ti­on ty­pi­scher­wei­se über die of­fi­zi­el­le App „OpenID Connect user backend“ (user_oidc), die externe Identity Provider wie Keycloak, Microsoft Entra ID, ADFS, Okta oder Shib­bo­leth anbinden kann. Community-Apps wie „Social Login“ exis­tie­ren ebenfalls, werden jedoch eher für ein­fa­che­re oder al­ter­na­ti­ve Login-Szenarien genutzt.

Für die Ein­rich­tung wird im Identity Provider zunächst ein OAuth2-Client erstellt. Dabei generiert der IdP eine Client ID und ein Client Secret. Zu­sätz­lich muss die Redirect- oder Callback-URL von Nextcloud hin­ter­legt werden, damit der Identity Provider nach er­folg­rei­cher Anmeldung korrekt zu­rück­lei­ten kann. In Nextcloud werden an­schlie­ßend die wich­tigs­ten OIDC-Parameter ein­ge­tra­gen. Dazu gehören die Client ID, das Client Secret sowie die URL zum OpenID-Provider-Kon­fi­gu­ra­ti­ons­do­ku­ment, häufig auch Discovery Endpoint genannt. Dieser ist je nach Identity Provider üb­li­cher­wei­se unter einem Pfad wie /.well-known/openid-configuration er­reich­bar und liefert au­to­ma­tisch die re­le­van­ten URLs für Au­to­ri­sie­rung, Token-Austausch und Be­nut­zer­in­for­ma­tio­nen.

Während der Anmeldung au­then­ti­fi­ziert sich der User beim Identity Provider. An­schlie­ßend erhält Nextcloud ein si­gnier­tes ID-Token, das Be­nut­zer­at­tri­bu­te wie Name, E-Mail-Adresse oder Grup­pen­in­for­ma­tio­nen enthält. Die Au­then­ti­fi­zie­rung erfolgt dabei über stan­dar­di­sier­te JSON Web Tokens (JWT). OIDC gilt als einfacher zu im­ple­men­tie­ren als SAML und in­te­griert sich besonders gut in moderne Web­ar­chi­tek­tu­ren. Funk­tio­nen wie MFA, Con­di­tio­nal Access oder die Gül­tig­keits­dau­er von Tokens werden dabei nicht durch OIDC selbst, sondern im Identity Provider kon­fi­gu­riert und durch­ge­setzt. OIDC kann relevante In­for­ma­tio­nen dazu über Claims wie amr oder acr an Nextcloud über­mit­teln.

Hinweis

In der Praxis erfolgt die Anmeldung meist über den Aut­ho­riza­ti­on Code Flow: Nextcloud erhält zunächst einen Au­to­ri­sie­rungs­code und tauscht diesen am Token-Endpoint gegen ein ID-Token und ein Access Token ein. Wenn vom Identity Provider un­ter­stützt, kann dieser Ablauf zu­sätz­lich mit PKCE (Proof Key for Code Exchange), häufig mit der Methode S256, ab­ge­si­chert werden.

Tech­ni­scher Vergleich: SAML vs. OIDC vs. LDAP

Die Wahl des passenden Au­then­ti­fi­zie­rungs­pro­to­kolls hängt von der vor­han­de­nen In­fra­struk­tur und den Si­cher­heits­an­for­de­run­gen ab. LDAP und Active Directory eignen sich primär als zentrale Be­nut­zer­ver­zeich­nis­se, während SAML und OIDC echtes web­ba­sier­tes Single Sign-on be­reit­stel­len.

Protokoll Kom­ple­xi­tät der Ein­rich­tung (manuell) Un­ter­stütz­te Features Primärer Use Case Si­cher­heits­le­vel
LDAP / Active Directory Mittel Benutzer- und Gruppen-Syn­chro­ni­sie­rung, Attribut-Mapping Zentrale Be­nut­zer­ver­wal­tung Hoch bei LDAPS/STARTTLS
SAML 2.0 Hoch SSO, Group Sync, signierte As­ser­ti­ons, zentrale Policies En­ter­pri­se-SSO in Un­ter­neh­mens­um­ge­bun­gen Sehr hoch
OpenID Connect (OIDC) Mittel OAuth2-In­te­gra­ti­on, Token-basierte Anmeldung, moderne APIs Web­an­wen­dun­gen und Cloud-native Um­ge­bun­gen Sehr hoch
LDAP + SAML Hoch Zentrale Be­nut­zer­ver­wal­tung plus web­ba­sier­tes SSO Klas­si­sche En­ter­pri­se-Ar­chi­tek­tu­ren Sehr hoch
LDAP + OIDC Mittel bis hoch Moderne SSO-Ar­chi­tek­tur mit zentralem Ver­zeich­nis­dienst IAM-Um­ge­bun­gen Sehr hoch

Best Practices und Trou­ble­shoo­ting

  • HTTPS kon­se­quent erzwingen: SAML-, OIDC- und LDAP-An­mel­de­da­ten dürfen niemals un­ver­schlüs­selt über­tra­gen werden. Für pro­duk­ti­ve Um­ge­bun­gen sind TLS-Zer­ti­fi­ka­te und eine voll­stän­di­ge HTTPS-Kon­fi­gu­ra­ti­on Pflicht.
  • Fallback-Admin-Konto lokal behalten: Min­des­tens ein lokaler Nextcloud-Admin sollte nicht über SSO au­then­ti­fi­ziert werden. Fehl­kon­fi­gu­ra­tio­nen im Identity Provider können sonst dazu führen, dass kein ad­mi­nis­tra­ti­ver Zugriff mehr möglich ist.
  • Ein­deu­ti­ge User-IDs verwenden: Attribute wie mail oder An­zei­ge­na­men können sich ändern. Stabile Iden­ti­fi­ka­to­ren wie objectGUID, entryUUID oder sub ver­hin­dern doppelte Be­nut­zer­kon­ten und Syn­chro­ni­sa­ti­ons­pro­ble­me.
  • Gruppen- und Be­nut­zer­fil­ter präzise de­fi­nie­ren: Unscharfe LDAP-Filter im­por­tie­ren häufig unnötige oder tech­ni­sche Accounts. Eine klare OU- und Grup­pen­struk­tur reduziert Fehler und ver­bes­sert die Per­for­mance.
  • Externe Nut­zer­kon­ten separat behandeln: Für externe Part­ne­rin­nen und Partner oder Pro­jekt­kon­ten sollten getrennte Gruppen, Quotas und Richt­li­ni­en definiert werden. Dadurch bleiben interne und externe Zu­griffs­rech­te sauber von­ein­an­der getrennt.
  • Logs sys­te­ma­tisch ana­ly­sie­ren: Fehl­ge­schla­ge­ne Logins lassen sich häufig über die Nextcloud-Logs sowie die Logs des Identity Providers nach­voll­zie­hen. Besonders relevant sind Assertion-Fehler, Token-Va­li­die­rung und feh­ler­haf­te Attribute.
  • Back­chan­nel-Logout prüfen: Wenn der Identity Provider OpenID Connect Back­chan­nel Logout un­ter­stützt, sollte die von user_oidc be­reit­ge­stell­te Back­chan­nel-Logout-URL im IdP hin­ter­legt werden. So kann der IdP Nextcloud über Logout-Er­eig­nis­se in­for­mie­ren und zu­ge­hö­ri­ge Nextcloud-Sitzungen gezielt beenden.
  • Zeit­syn­chro­ni­sie­rung si­cher­stel­len: SAML-As­ser­ti­ons und OIDC-Tokens sind zeit­ab­hän­gig. Un­ter­schied­li­che Sys­tem­zei­ten zwischen Nextcloud und Identity Provider führen häufig zu un­gül­ti­gen Tokens oder ab­ge­lehn­ten As­ser­ti­ons.
  • Test­um­ge­bung vor Pro­duk­tiv­be­trieb verwenden: Än­de­run­gen an SSO-Kon­fi­gu­ra­tio­nen sollten zuerst in einer separaten Umgebung getestet werden. Feh­ler­haf­te Metadaten oder falsche Redirect-URLs können den Login-Prozess voll­stän­dig blo­ckie­ren.
Zum Hauptmenü