Verfügbarkeit
Pakete: Als Add-On für Enterprise buchbar
Nutzerrollen: Admin
remberg ermöglicht deinem Team die Anmeldung über den Identity Provider deines Unternehmens statt über ein separates remberg-Passwort. Du konfigurierst erweiterte SSO-Verbindungen direkt in remberg unter Einstellungen → Sicherheit → Single Sign-On, ohne Zugangsdaten an den remberg Support zu übermitteln.
Welche Optionen gibt es?
Microsoft Entra ID (OIDC) – empfohlen für die meisten Microsoft-Kunden mit mehreren Workspaces oder individuellen Policy-Anforderungen
Microsoft Entra ID (SAML 2.0) – für Organisationen, die auf SAML standardisiert sind
Okta (OIDC) – Beta
Diese Optionen bestehen zusätzlich zur integrierten Anmeldung per E-Mail/Passwort mit optionaler Zwei-Faktor-Authentifizierung über Authenticator-Apps.
💡 Hinweis: SSO authentifiziert Nutzer ausschließlich anhand der vom Identity Provider übermittelten E-Mail-Adresse. Es erstellt, synchronisiert oder vergibt keine Rollen (kein SCIM/User Provisioning). Nutzer müssen bereits in remberg existieren, und ihre remberg-E-Mail-Adresse muss exakt mit der E-Mail-Adresse im Identity Provider übereinstimmen, damit die SSO-Anmeldung funktioniert.
Wann welche Methode?
Methode | Wann geeignet |
Microsoft Entra (OIDC) | Mehrere remberg-Workspaces oder eigene Policy-Anforderungen über eine eigene App-Registrierung. Self-Service. |
Microsoft Entra (SAML) | Deine Organisation setzt auf das SAML-Protokoll. |
Okta (OIDC) | Du nutzt Okta als Identity Provider. |
💡 Hinweis: Pro Workspace kann jeweils nur eine Erweiterte SSO-Verbindung aktiv sein. Der Standard Microsoft Login läuft unabhängig davon.
Bevor du startest
Stelle sicher, dass Folgendes vorhanden ist:
Das erweiterte SSO-Feature ist in deinem Vertrag. Prüfe mit deinem Customer Success Manager, falls die Seite fehlt.
Tenant Owner-Zugriff in remberg mit der Berechtigung Anzeigen und Bearbeiten von Passwörtern.
Administratorzugriff auf deinen Identity Provider (Microsoft Entra Admin Center oder Okta Admin Console).
Bereits existierende Nutzer in remberg. Lege Nutzer an oder importiere sie, bevor sie SSO nutzen – mit E-Mail-Adressen, die exakt mit deinem Identity Provider übereinstimmen.
Wo du es findest: Einstellungen → Sicherheit → Single Sign-On.
Die Einrichtung erfolgt in zwei Schritten:
remberg zeigt dir Werte an, die du in deinem Identity Provider hinterlegst (zuerst die Redirect URI).
Dein Identity Provider gibt dir Werte, die du zurück in remberg einträgst (Client ID, Secret, Issuer oder Metadata-URL).
💡 Hinweis: Kopiere die Redirect URI immer exakt so, wie sie auf der Seite Single Sign-On angezeigt wird – sie ist spezifisch für deine Umgebung. In Produktion lautet sie: https://login.remberg.com/ui/login/login/externalidp/callback
Methode 1: Microsoft Entra ID (OIDC)
Empfohlen bei mehreren Workspaces oder individueller Policy-Kontrolle.
Schritt 1: Anwendung in Microsoft Entra registrieren
Gehe im Microsoft Entra Admin Center zu Identity → Applications → App registrations → New registration.
Vergib einen Namen (z. B. remberg SSO).
Unter Supported account types reicht Single tenant aus – remberg verbindet sich über die Directory (Tenant) ID, die du später eingibst, mit deinem Verzeichnis.
Wähle unter Redirect URI die Plattform Web und füge die Redirect URI von der remberg-Seite Single Sign-On ein.
Klicke auf Register und notiere dir die Application (client) ID sowie die Directory (tenant) ID.
Schritt 2: Client-Secret erstellen
Gehe zu Certificates & secrets → + New client secret.
Ergänze eine Beschreibung und ein Ablaufdatum.
Kopiere den Secret-Value sofort – Entra zeigt ihn nur einmal an.
Schritt 3: Token-Claims konfigurieren
Gehe zu Token configuration → + Add optional claim.
Wähle den Token-Typ ID.
Füge diese vier Claims hinzu: email, given_name, family_name, preferred_username.
Schritt 4: API-Berechtigungen setzen
Gehe zu API permissions.
Stelle sicher, dass diese delegierten Microsoft Graph-Berechtigungen erteilt sind: openid, email, profile, User.Read (openid wird meist automatisch ergänzt).
Ist die Nutzerzustimmung in deiner Organisation deaktiviert, klicke auf Grant admin consent, damit Nutzer bei der ersten Anmeldung nicht blockiert werden.
Schritt 5: In remberg verbinden
Öffne Einstellungen → Sicherheit → Single Sign-On und wähle Microsoft Entra (OIDC).
Trage Application (client) ID, Directory (tenant) ID und Client secret ein.
Klicke auf Test connection – das prüft die drei Werte gegen Microsoft, ohne jemanden anzumelden.
Klicke auf Set up SSO und aktiviere anschließend SSO active.
Methode 2: Microsoft Entra ID (SAML 2.0)
Führe die Schritte in dieser Reihenfolge aus – beide Seiten tauschen URLs miteinander aus.
Schritt 1: Erweiterte Anwendung in Entra erstellen
Gehe im Microsoft Entra Admin Center zu Identity → Applications → Enterprise applications → New application → Create your own application.
Wähle Integrate any other application you don't find in the gallery (Non-gallery) und erstelle die Anwendung.
Öffne Single sign-on → SAML.
Kopiere im Bereich SAML Certificates die App Federation Metadata URL.
Schritt 2: Einrichtung in remberg starten
Öffne Einstellungen → Sicherheit → Single Sign-On und wähle Microsoft Entra (SAML).
Füge die App Federation Metadata URL ein und klicke auf Set up SSO.
remberg zeigt dir jetzt die Identifier (Entity ID) und Reply URL (ACS URL) an. Lasse diese Seite geöffnet.
Schritt 3: SAML-Konfiguration in Entra abschließen
Bearbeite Basic SAML Configuration und trage ein:
Identifier (Entity ID) – aus remberg
Reply URL (Assertion Consumer Service URL) – aus remberg (Produktion: https://login.remberg.com/ui/login/login/externalidp/saml/acs)
Stelle unter Attributes & Claims sicher, dass die Anwendung nameidentifier und emailaddress sendet.
Weise unter Users and groups die Personen zu, die Zugriff erhalten sollen.
💡 Hinweis: E-Mail-Abgleich ist Voraussetzung. remberg liest den emailaddress-Claim aus und greift auf die Name ID (den UPN des Nutzers) zurück, falls in Entra kein Postfach hinterlegt ist. Stelle sicher, dass einer der beiden Werte die E-Mail-Adresse des Nutzers enthält – sonst schlägt die Anmeldung fehl.
Schritt 4: Aktivieren
Aktiviere in remberg SSO active.
Methode 3: Okta (OIDC) (Beta)
Schritt 1: App-Integration in Okta erstellen
Gehe in der Okta Admin Console zu Applications → Applications → Create App Integration.
Wähle OIDC - OpenID Connect, dann Web Application.
Vergib einen Namen (z. B. remberg).
Füge unter Sign-in redirect URIs die Redirect URI von der remberg-Seite Single Sign-On ein.
Weise unter Assignments die Nutzer oder Gruppen zu, die Zugriff erhalten sollen.
Speichere und kopiere anschließend Client ID und Client secret.
Schritt 2: Scopes und Issuer prüfen
remberg fordert openid, profile und email an. email ist für den Nutzerabgleich erforderlich; die Standard-OIDC-Scopes benötigen keine zusätzliche Okta-Konfiguration.
Deine Issuer URL entspricht deiner Okta-Domain, z. B. https://your-org.okta.com.
Schritt 3: In remberg verbinden
Öffne Einstellungen → Sicherheit → Single Sign-On und wähle Okta (OIDC).
Trage Issuer URL, Client ID und Client secret ein.
Klicke auf Set up SSO und aktiviere anschließend SSO active.
So überprüfst du, ob es funktioniert hat
Melde dich aus remberg ab.
Klicke auf der Login-Seite deines Workspaces auf den Single-Sign-On-Button (bzw. "Login with Microsoft" bei der Standard-Option).
Du wirst zu deinem Identity Provider weitergeleitet, authentifiziert und zurück zu remberg geführt.
Prüfe, ob du als der richtige Nutzer mit den erwarteten Berechtigungen angemeldet bist.
💡 Hinweis: Der erweiterte SSO-Button erscheint nur, wenn SSO active eingeschaltet ist. Du kannst ihn jederzeit ausschalten, um den Button auszublenden, ohne die Konfiguration zu löschen.
Wichtig zu wissen
Nutzer müssen vorher existieren (kein SCIM/Provisioning)
Problem: Die Anmeldung schlägt fehl, wenn der Nutzer noch nicht in remberg existiert.
Lösung: Lege Nutzer an oder importiere sie in remberg, bevor sie SSO nutzen – mit einer E-Mail-Adresse, die exakt dem Claim des Identity Providers entspricht.
Secret-Ablauf und Rotation (OIDC)
Problem: Client-Secrets bei Entra und Okta laufen ab. Läuft ein Secret ab, funktioniert SSO für alle Nutzer nicht mehr.
Lösung: Erstelle rechtzeitig vor dem Ablauf ein neues Client-Secret bei deinem Provider, öffne die Seite Single Sign-On in remberg, trage das neue Secret ein und speichere. Lässt du das Feld leer, bleibt das aktuelle Secret bestehen. remberg speichert oder zeigt dein Secret nach dem Speichern nie wieder an.
Provider wechseln
Es kann immer nur eine erweiterte SSO-Verbindung gleichzeitig aktiv sein. Um zu wechseln (z. B. von Entra OIDC zu Okta), nutze Remove SSO und richte anschließend den neuen Provider ein. Die Entfernung deaktiviert die Verbindung und räumt die Verknüpfungen zum Identity Provider im Hintergrund auf.
Fehlerbehebung
Symptom | Wahrscheinliche Ursache | Lösung |
Test connection schlägt fehl (Entra OIDC) | Falsche Client ID, Secret oder Tenant ID; abgelaufenes Secret | Werte prüfen; bei Ablauf ein neues Client-Secret erstellen |
"Redirect URI mismatch" bei der Anmeldung | Redirect URI im Provider stimmt nicht mit remberg überein | Redirect URI von der Seite Single Sign-On exakt kopieren und erneut einfügen |
Anmeldung beim Provider erfolgreich, aber nicht in remberg | Nutzer existiert nicht in remberg, oder keine E-Mail im Token | Prüfen, ob der Nutzer mit passender E-Mail existiert; OIDC: email-Claim/Scope prüfen; SAML: emailaddress (oder eine UPN, die die E-Mail ist) prüfen |
SAML-Fehler AADSTS700016 | Entity ID nicht in Entra registriert | Identifier (Entity ID) aus remberg in die Basic SAML Configuration in Entra einfügen |
SSO-Button erscheint nicht beim Login | SSO nicht aktiviert | SSO active auf der Seite Single Sign-On einschalten |
Weiterhin Probleme? Kontaktiere den remberg Support mit deinem Provider-Typ (Entra OIDC / Entra SAML / Okta) und der genauen Fehlermeldung.
FAQ
Legt SSO automatisch neue Nutzer in remberg an (SCIM)? Nein. SSO authentifiziert nur bestehende Nutzer. Nutzer müssen vorher in remberg angelegt oder importiert werden, mit einer E-Mail-Adresse, die exakt mit dem Identity Provider übereinstimmt.
Kann ich mehrere erweiterte SSO-Methoden gleichzeitig nutzen? Nein, pro Workspace ist immer nur eine erweiterte SSO-Verbindung aktiv. Der Standard Microsoft Login läuft unabhängig davon und kann parallel bestehen.
Was passiert, wenn das Client-Secret abläuft? Die SSO-Anmeldung schlägt für alle Nutzer fehl. Erstelle vor Ablauf ein neues Secret bei deinem Provider und trage es in remberg ein.
Ein Nutzer kann sich beim Identity Provider anmelden, kommt aber nicht in remberg an – was tun? Prüfe, ob der Nutzer bereits in remberg existiert und ob die E-Mail-Adresse exakt übereinstimmt. Bei OIDC den email-Claim/Scope prüfen, bei SAML den emailaddress-Claim (oder eine UPN, die der E-Mail-Adresse entspricht).