Skip to main content
server.camp Docs
server.camp Docs
server.camp Wechsel zwischen Dunkel/Hell/Auto Modus Wechsel zwischen Dunkel/Hell/Auto Modus Wechsel zwischen Dunkel/Hell/Auto Modus Zurück zur Startseite
  1. Dokumentation
  2. /
  3. Dienste
  4. /
  5. GitLab
  6. /
  7. Single Sign-On (SSO) einrichten

Single Sign-On (SSO) einrichten

Feedback zu dieser Seite

Du kannst deine Managed GitLab bei server.camp so konfigurieren, dass sich Nutzer per Single Sign-On (SSO) mit ihrem zentralen Konto anmelden. GitLab nutzt dafür den Standard OpenID Connect (über OmniAuth) – es funktioniert also mit Authentik, Keycloak, Zitadel, Microsoft Entra ID, Google Workspace und anderen OIDC-fähigen Providern. Diese Anleitung zeigt das Vorgehen am Beispiel von Authentik.

Die Einrichtung erfolgt vollständig als Self-Service im server.camp-Portal und ist auf allen Tarifen verfügbar.

OpenID Connect statt SAML
GitLab unterstützt sowohl SAML als auch OpenID Connect. Diese Anleitung behandelt die Anbindung über OpenID Connect, da sie im server.camp-Portal ohne Zusatzkonfiguration verfügbar ist.

Voraussetzungen

  • Ein aktives GitLab-Abonnement bei server.camp
  • Eine erreichbare, OIDC-fähige Identity-Provider-Instanz (z. B. Managed Authentik bei server.camp)
  • Admin-Zugang zu beiden Systemen

Schritt 1 – Provider in Authentik anlegen

  1. In Authentik öffne Anwendungen → Provider
  2. Klicke auf “Erstellen” → Typ: OAuth2/OpenID Connect
  3. Fülle die Felder aus:
  • Name: GitLab
  • Client Type: Confidential
  • Redirect URIs: 
    https://<deine-gitlab-domain>/users/auth/openid_connect/callback
  • Signing Key: Den Standardschlüssel auswählen (bereits vorhanden)
  1. Speichern – Authentik generiert automatisch Client ID und Client Secret.
Client ID und Secret notieren
Öffne den gerade erstellten Provider erneut und kopiere Client ID und Client Secret in einen Texteditor. Du brauchst beide Werte später im server.camp-Portal.

Schritt 2 – Anwendung in Authentik anlegen

  1. Gehe zu Anwendungen → Anwendungen → “Erstellen”
  2. Felder ausfüllen:
  • Name: GitLab
  • Slug: gitlab (diesen Wert brauchst du gleich für die Issuer-URL)
  • Provider: den gerade erstellten GitLab-Provider auswählen
  1. Optional: Unter UI Einstellungen ein GitLab-Logo hochladen und die Launch-URL auf https://<deine-gitlab-domain> setzen
  2. Speichern

Zugang auf Gruppen beschränken (empfohlen): Öffne die Anwendung → Reiter Policy / Group / User Bindings → “Erstellen” → Group → diejenige Gruppe wählen, die Zugang zu GitLab erhalten soll (z. B. alle-mitarbeiter). So können sich nur Mitglieder dieser Gruppe über SSO in GitLab anmelden.

Schritt 3 – Issuer-URL ermitteln

GitLab nutzt Discovery: Statt jeden Endpunkt einzeln zu hinterlegen, brauchst du nur die Issuer-URL. GitLab liest daraus automatisch alle weiteren Endpunkte. Die Issuer-URL hat bei Authentik die folgende Form (mit abschließendem Schrägstrich):

https://<deine-authentik>/application/o/<slug>/

Ersetze <deine-authentik> durch deine tatsächliche Authentik-Adresse und <slug> durch den Slug aus Schritt 2, z. B.:

https://dein-authentik.srv.camp/application/o/gitlab/
Issuer-URL prüfen
Hänge zum Testen .well-known/openid-configuration an die Issuer-URL an und rufe sie im Browser auf. Erscheint eine JSON-Antwort, ist die Issuer-URL korrekt.

Schritt 4 – GitLab im server.camp-Portal konfigurieren

Öffne im Kundenportal die Konfiguration deines GitLab-Abonnements und trage die folgenden Werte ein:

Feld Wert
Single Sign-On aktivieren Angehakt
Anzeigename des Login-Buttons Frei wählbar, Standard SSO – erscheint als Beschriftung des Login-Buttons
Issuer-URL Issuer-URL aus Schritt 3 (mit abschließendem Schrägstrich)
Client-ID Aus Authentik kopiert (Schritt 1)
Client-Secret Aus Authentik kopiert (Schritt 1)

Speichern und warten, bis die Bereitstellung abgeschlossen ist (ca. 2–3 Minuten). Auf der Login-Seite von GitLab erscheint danach zusätzlich ein Button zur Anmeldung über deinen Provider.

Schritt 5 – Neue Nutzer freischalten und bestehende verknüpfen

Für den Umgang mit Benutzerkonten stehen zwei zusätzliche Optionen zur Verfügung:

Feld Standard Wirkung
Neue SSO-Nutzer sperren An Neue, per SSO angelegte Nutzer werden zunächst gesperrt und müssen von einem Admin freigeschaltet werden, bevor sie GitLab nutzen können.
Bestehende Nutzer verknüpfen Aus Verknüpft ein bestehendes GitLab-Konto beim ersten SSO-Login automatisch anhand der E-Mail-Adresse mit dem SSO-Konto.
Nur SSO-Login Aus Deaktiviert die Passwort-Anmeldung im Web — Anmeldung nur noch über SSO.

Neue Nutzer freischalten: Ist “Neue SSO-Nutzer sperren” aktiviert (Standard), landen neu per SSO angelegte Konten im Status gesperrt. Ein Admin gibt sie unter Admin-Bereich → Übersicht → Benutzer frei. So verhinderst du, dass sich unbeabsichtigt Personen aus deinem Identity-Provider Zugang zu Gitlab verschaffen.

Bestehende Nutzer verknüpfen: Aktivierst du “Bestehende Nutzer verknüpfen”, wird beim ersten SSO-Login ein bereits vorhandenes GitLab-Konto mit derselben E-Mail-Adresse automatisch mit dem SSO-Konto verbunden. So müssen bestehende Nutzer kein neues Konto anlegen.

Sicherheitshinweis zur automatischen Verknüpfung
Aktiviere “Bestehende Nutzer verknüpfen” nur, wenn dein Identity-Provider E-Mail-Adressen verifiziert. Andernfalls könnte sich jemand mit einer nicht verifizierten, fremden E-Mail-Adresse anmelden und so ein bestehendes GitLab-Konto übernehmen (Account-Takeover). Im Zweifel lässt du diese Option ausgeschaltet und verknüpfst Konten manuell.

Nur SSO-Login erzwingen: Mit der Option “Nur SSO-Login” wird die Passwort-Anmeldemaske im Web ausgeblendet — Nutzer können sich dann ausschließlich über deinen Identity-Provider anmelden. Git-Zugriff über HTTPS (mit Personal Access Token) und SSH bleibt davon unberührt.

Aussperr-Gefahr – erst SSO testen, dann erzwingen
“Nur SSO-Login” gilt für alle Konten, auch für root/Admin. Aktiviere die Option erst, wenn du dich mit einem Admin-Konto erfolgreich per SSO anmelden kannst (Konto per SSO verknüpft und – bei aktivem “Neue SSO-Nutzer sperren” – freigeschaltet). Andernfalls sperrst du dich komplett aus; die Anmeldung lässt sich dann nur durch erneutes Deployment mit deaktivierter Option wiederherstellen. Empfehlung: SSO vollständig testen, ein Admin-Konto verknüpfen und erst danach “Nur SSO-Login” einschalten.

Schritt 6 – Login testen

  1. Melde dich in GitLab ab
  2. Auf der Login-Seite erscheint nun ein Button mit der von dir gewählten Beschriftung (Standard SSO)
  3. Klicke darauf – du wirst zu Authentik weitergeleitet
  4. Nach der Authentifizierung (und ggf. 2FA) landest du zurück in GitLab
Erst testen, dann umstellen
Der klassische GitLab-Login bleibt neben dem SSO-Button erhalten. So kommst du bei einer fehlerhaften Konfiguration weiterhin mit deinem lokalen Admin-Konto hinein.

Fehlerbehebung

  • “redirect_uri mismatch” beim IdP: Prüfe, ob die Redirect-URI in Authentik exakt hinterlegt ist – inklusive https:// und Pfad (/users/auth/openid_connect/callback). Sie muss exakt mit deiner GitLab-Domain übereinstimmen.
  • Kein SSO-Button sichtbar: Ist “Single Sign-On aktivieren” angehakt und die Bereitstellung im Portal abgeschlossen?
  • Anmeldung funktioniert, aber der Account ist gesperrt: Das ist beim ersten Login mit aktivierter Option “Neue SSO-Nutzer sperren” normal. Ein Admin schaltet den Nutzer unter Admin-Bereich → Übersicht → Benutzer frei.
  • Issuer-Fehler / Endpunkte werden nicht gefunden: Prüfe, ob die Issuer-URL mit einem abschließenden Schrägstrich endet und die Discovery-URL (.well-known/openid-configuration) im Browser erreichbar ist.

Noch Fragen?

Bei Fragen zur SSO-Integration erreichst du unseren Support über das Kundenportal.

GitLab – Erste Schritte GitLab – Bestehendes GitLab migrieren