Zum Hauptinhalt springen

Documentation Index

Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt

Use this file to discover all available pages before exploring further.

Dieser Leitfaden führt Enterprise-Administratoren durch den gesamten SSO-Ablauf mit Devin — von der Ersteinrichtung bis zur Konfiguration von IDP-Gruppen — und erläutert, wie Devin die Nutzerbereitstellung ohne SCIM handhabt. Anbieterspezifische Anleitungen zur Einrichtung finden Sie unter Okta, Azure AD, SAML oder Generic OIDC.

1. SSO (Single Sign-On) einrichten

Erstellen Ihrer SSO-Anwendung

Erstellen Sie eine Anwendung in Ihrem Identity Provider (Okta, Azure AD oder einem beliebigen SAML-/OIDC-kompatiblen IdP) und teilen Sie Ihrem Cognition-Team die folgenden Anmeldedaten mit:
VerbindungstypProtokollBereitzustellende Angaben
OktaOIDC (Okta Workforce Identity)Okta-Domain, Client ID, Client Secret, Geltungsbereiche
Azure ADOIDC (Microsoft Entra ID)Azure AD-Domain, Client ID, Client Secret
SAMLSAML 2.0 (beliebiger IdP)Anmelde-URL, X.509-Signaturzertifikat
Generic OIDCOIDCDiscovery-URL, Client ID, Client Secret, Geltungsbereiche
Geben Sie außerdem Ihre verifizierten E-Mail-Domänen an, damit Devin weiß, welchen E-Mail-Adressen aus Ihrem IdP vertraut werden kann.

Was nach der Einrichtung passiert

Sobald Ihr Cognition-Team über die Zugangsdaten verfügt, konfiguriert es die SSO-Verbindung. Nachdem die Einrichtung abgeschlossen ist:
  1. Die SSO-Verbindung wird mit Ihrem Devin Enterprise verknüpft
  2. Automatische Mitgliedschaft bei der Anmeldung ist aktiviert — jeder Nutzer, der sich über SSO authentifiziert, wird automatisch zu Ihrem Enterprise hinzugefügt
  3. Ihre E-Mail-Domain(s) werden als vertrauenswürdig registriert — nur E-Mail-Adressen aus diesen Domains werden akzeptiert
  4. Gruppenbasierte Rollenzuweisung (RBAC) ist aktiviert — IdP-Gruppen, die bei der Anmeldung übermittelt werden, können Devin-Rollen zugeordnet werden
  5. Standardmäßige Social Logins (Google, GitHub) sind deaktiviert — SSO wird zur verpflichtenden Authentifizierungsmethode

Das Anmeldeerlebnis für Nutzer

  1. Der Nutzer ruft Ihre Devin-URL auf
  2. Wird an den konfigurierten IdP (Okta, Azure AD usw.) weitergeleitet
  3. Der Nutzer authentifiziert sich wie gewohnt
  4. Der IdP sendet Nutzerinformationen und Gruppenzugehörigkeiten an Devin
  5. Devin übernimmt automatisch Folgendes:
    • Erstellt das Konto des Nutzers, wenn es sich um die erste Anmeldung handelt (Just-in-Time-Provisionierung)
    • Weist ihm die Standardrolle „Enterprise Member“ zu
    • Synchronisiert die IdP-Gruppenzugehörigkeiten — fügt neue Gruppen hinzu und entfernt veraltete Gruppen
    • Protokolliert die Anmeldung im Enterprise-Audit-Log

Self-Service-Administration

Die folgenden Funktionen stehen Unternehmensadministratoren direkt in der Devin-Webapp zur Verfügung.

Verwaltung von IdP-Gruppen

Settings → Enterprise → Identity Provider Groups
  • Alle Gruppen anzeigen, die über Nutzeranmeldungen synchronisiert wurden
  • Einer Gruppe eine Rolle auf Enterprise-Ebene zuweisen (z. B. „Jeder in Engineering-Admins erhält die Rolle Enterprise Admin“)
  • Einer Gruppe bestimmte Orgs mit bestimmten Rollen zuweisen (z. B. „Team-Backend erhält Member-Zugriff in der Backend-Org“)
  • Gruppen org-übergreifend in mehreren Orgs gesammelt hinzufügen/entfernen
  • Anzeigen, wie vielen Orgs jede Gruppe zugewiesen ist

Mitgliederverwaltung

Settings → Enterprise → Mitglieder
  • Alle Enterprise-Mitglieder anzeigen, einschließlich ihrer IdP-Gruppenzugehörigkeiten
  • Neue Mitglieder per E-Mail einladen
  • Rollen von Mitgliedern aktualisieren
  • Mitglieder entfernen

Benutzerdefinierte Rollen

Settings → Enterprise → Rollen
  • Erstellen Sie benutzerdefinierte Rollen mit feingranularen Berechtigungen
  • Weisen Sie benutzerdefinierte Rollen einzelnen Nutzern oder IDP-Gruppen zu
Weitere Informationen finden Sie unter Custom Roles & RBAC.

API zur Automatisierung

Devin stellt eine V2-API bereit, mit der Sie die Mitgliederverwaltung automatisieren können:
AktionAPI-Endpunkt
Alle Mitglieder auflistenGET /v2/enterprise/members
Nutzer per E-Mail gesammelt einladenPOST /v2/enterprise/members/invite
Ein Mitglied entfernenDELETE /v2/enterprise/members/{user_id}
Rollen mehrerer Mitglieder gesammelt aktualisierenPATCH /v2/enterprise/members/roles
Mitglieder zwischen Rollen migrierenPATCH /v2/enterprise/members/migrate-roles
Alle Rollen auflistenGET /v2/enterprise/roles
Alle IdP-Gruppen auflistenGET /v2/enterprise/groups
IdP-Gruppen vorab erstellenPUT /v2/enterprise/groups
Org-Zuweisungen einer Gruppe abrufenGET /v2/enterprise/groups/{group_name}

2. Devin ohne SCIM

Devin unterstützt das SCIM-Protokoll derzeit nicht. Die gesamte Nutzer- und Gruppenverwaltung erfolgt über SSO-Anmeldungen sowie über die Devin-UI/API. Das bedeutet in der Praxis Folgendes.

Nutzerbereitstellung: Nur beim Login ausgelöst

Mit SCIMDevin (ohne SCIM)
Wie Nutzer angelegt werdenDer IdP legt den Nutzer in der App sofort an, sobald er ihm zugewiesen wirdDer Nutzer existiert in Devin erst nach seiner ersten SSO-Anmeldung — oder nach einer manuellen Einladung über die UI oder API
Wann es passiertAdmin weist dem Nutzer die App zu → der Nutzer erscheint innerhalb weniger SekundenAdmin weist dem Nutzer die App zu → in Devin passiert nichts, bis er sich anmeldet
VorabbereitstellungDas Nutzerkonto ist bereit, bevor der Nutzer die App überhaupt besuchtKeine Vorabbereitstellung, es sei denn, der Admin lädt den Nutzer ausdrücklich über die Devin UI oder API ein
Beim Onboarding neuer Mitarbeiter kann der Admin sie entweder im Voraus einladen (Settings → Enterprise → Members → Invite oder über die API) oder sie einfach bei der ersten Anmeldung automatisch anlegen lassen.

Benutzer-Deprovisionierung: nur manuell

Mit SCIMDevin (ohne SCIM)
Wie Nutzer entfernt werdenIdP deaktiviert/entfernt Nutzer → die App deaktiviert den Nutzer sofortDas Deaktivieren/Entfernen eines Nutzers im IdP hat in Devin keine Wirkung
OffboardingAusgeschiedene Mitarbeitende verlieren innerhalb weniger Minuten den ZugriffAusgeschiedene Mitarbeitende behalten den Zugriff, bis sie manuell aus Devin entfernt werden und ihre Sitzung abläuft
ComplianceAutomatisierte Compliance — keine verwaisten KontenRisiko verwaister Konten, wenn der Admin nicht beide Systeme pflegt
Dies ist die größte operative Lücke. Beim Offboarding eines Mitarbeitenden muss der Admin die Person zusätzlich aus Devin entfernen (Settings → Enterprise → Members → Remove oder über die API). Aktive Sitzungen laufen weiter, bis sie von selbst ablaufen — es gibt keinen sofortigen Sitzungsentzug, der durch den IdP ausgelöst wird.

Gruppensynchronisierung: Nur bei der Anmeldung, nicht in Echtzeit

Mit SCIM (Group Push)Devin (ohne SCIM)
Zeitpunkt der SynchronisierungDer IdP überträgt Änderungen an Gruppenmitgliedschaften in EchtzeitGruppen werden nur synchronisiert, wenn sich der Nutzer anmeldet
Zu einer Gruppe hinzufügenAdmin fügt Nutzer zu einer Gruppe hinzu → die App übernimmt dies sofortAdmin fügt Nutzer zu einer Gruppe hinzu → Devin erkennt dies erst bei der nächsten Anmeldung des Nutzers
Aus einer Gruppe entfernenAdmin entfernt Nutzer aus einer Gruppe → die App übernimmt dies sofortAdmin entfernt Nutzer aus einer Gruppe → Devin zeigt bis zur nächsten Anmeldung weiterhin die alte Mitgliedschaft an
Maßgebliche QuelleDer IdP ist immer die maßgebliche QuelleDer IdP ist nur bei der Anmeldung die maßgebliche Quelle — zwischen Anmeldungen können Abweichungen entstehen
Wenn ein Admin die IDP-Gruppe einer Person ändert (z. B. indem sie von Engineering zu Sales verschoben wird), übernimmt Devin diese Änderung erst, wenn sich der Nutzer erneut anmeldet. Bis dahin behält der Nutzer seine bisherigen gruppenbasierten Rollen und den Org-Zugriff.

Integrierte Alternativen zu SCIM

Devin bietet mehrere Funktionen, die gängige SCIM-Anwendungsfälle abdecken:
  1. Just-in-Time-Provisionierung — Nutzer werden bei der ersten SSO-Anmeldung automatisch mit der Standard-Enterprise-Rolle erstellt
  2. Vollständige Gruppensynchronisierung bei jeder Anmeldung — bei jeder Anmeldung führt Devin einen vollständigen Abgleich der IdP-Gruppen eines Nutzers durch: neue Gruppen werden hinzugefügt, alte entfernt
  3. Gruppenbasiertes RBAC — Sie können IdP-Gruppen in den Devin Settings Enterprise-Rollen und dem Org-Zugriff zuordnen; wirksam ab der nächsten Anmeldung
  4. V2-API für Automatisierung — Einladungen, Entfernungen und Rollenänderungen in großem Umfang lassen sich skripten, um die Lücke bei der Provisionierung und Deprovisionierung zu schließen
  5. Audit-Logs — jede Anmeldung wird protokolliert, sodass nachvollziehbar ist, wer auf Devin zugegriffen hat

3. Konfiguration von durch den IdP verwalteten Gruppen

Wenn Sie SCIM mit anderen Anwendungen (z. B. Slack, Box) verwenden, wird in diesem Abschnitt erläutert, wie das Gruppenmodell von Devin funktioniert und wie Sie Ihren IdP korrekt konfigurieren.

Kontext: SCIM-Gruppen vs. IdP-Gruppen

  • SCIM-Gruppen: Die nachgelagerte Anwendung teilt dem IdP mit, welche Gruppen es gibt (der IdP „importiert“ sie). Die Anwendung ist die maßgebliche Quelle für die Gruppenstruktur. Der IdP synchronisiert Nutzer in diese von der Anwendung definierten Gruppen.
  • IdP-Gruppen (wie von Devin verwendet): Der IdP ist die maßgebliche Quelle. Gruppen werden im Verzeichnis des IdP definiert, und Gruppenmitgliedschaften werden beim Anmelden über SAML/OIDC-Claims an Devin übermittelt.
Da Devin SCIM nicht verwendet, arbeiten Sie bereits im Modus „IdP-Gruppen“. Entscheidend ist, dass die richtigen Gruppen von Ihrem IdP gesendet und in Devin korrekt zugeordnet werden.

Schritt 1: Groups im IdP definieren

In der Admin-Konsole Ihres IdP (in den folgenden Beispielen wird Okta verwendet):
  1. Gehen Sie zu Directory → Groups
  2. Erstellen Sie Gruppen, die den Devin-Zugriffsstufen entsprechen (z. B. Devin-Engineering, Devin-Admins, Devin-DataScience)
  3. Weisen Sie Nutzer diesen Gruppen zu
Dies sind nativ im IdP verwaltete Gruppen — Ihr IdP ist die maßgebliche Quelle dafür, wer welcher Gruppe angehört.

Schritt 2: Gruppen-Claims in der IdP-App konfigurieren

Die Gruppen müssen in der Authentifizierungsantwort enthalten sein, damit Devin sie lesen kann.

Für SAML-Verbindungen

  1. Gehen Sie zu Applications → [Devin App] → SAML Settings → Edit
  2. Fügen Sie unter Group Attribute Statements Folgendes hinzu:
    • Name: groups
    • Filter: „Beginnt mit“ → Devin- (oder verwenden Sie „Entspricht Regex“ für komplexere Muster)
  3. Damit wird der IdP angewiesen, passende Gruppennamen in die SAML-Assertion aufzunehmen

Für OIDC-Verbindungen

  1. Gehen Sie zu Applications → [Devin App] → Sign On → Edit
  2. Wählen Sie unter OpenID Connect ID Token → Groups claim type „Filter“ aus
  3. Stellen Sie den Filter so ein, dass Devin-Gruppen erfasst werden (z. B. „Starts with“ → Devin-)
Verwenden Sie ein Filterpräfix wie Devin-, damit nur relevante Gruppen gesendet werden. Es ist nicht erforderlich, jede IDP-Gruppe in der Organisation zu senden.

Schritt 3: Gruppen in Devin Rollen und Orgs zuordnen

Sobald die Gruppen bei der Anmeldung übermittelt werden, ordnen Sie sie in Devin Rollen und Orgs zu.

In der Devin-UI

  1. Settings → Enterprise → Identity Provider Groups
  2. Gruppen werden automatisch angezeigt, sobald sich ein Mitglied dieser Gruppe anmeldet
  3. Klicken Sie auf eine Gruppe → weisen Sie ihr eine Rolle auf Enterprise-Ebene zu (z. B. Enterprise Admin oder eine benutzerdefinierte Rolle)
  4. Klicken Sie auf eine Gruppe → weisen Sie sie bestimmten Orgs mit bestimmten Rollen auf Org-Ebene zu

Über die API (für die Vorab-Einrichtung oder Automatisierung)

  • Gruppen vorab erstellen, bevor sich jemand anmeldet: PUT /v2/enterprise/groups
  • Gruppen und ihre Org-Zuweisungen auflisten: GET /v2/enterprise/groups

Schritt 4: Wenn Sie von SCIM-Gruppen in anderen Apps migrieren

Wenn Sie Ihre allgemeine IdP-Strategie in Ihrer gesamten Tool-Landschaft von SCIM-verwalteten Gruppen auf IdP-verwaltete Gruppen umstellen (nicht nur in Devin):
  1. SCIM-Gruppenimport in den anderen Apps beenden:
    • Im IdP: Wechseln Sie zur Registerkarte Provisioning → Integration der App → deaktivieren Sie „Import Groups“
    • Dadurch ist die nachgelagerte App nicht länger die maßgebliche Quelle für Gruppen
  2. Entsprechende Gruppen im IdP-Verzeichnis erstellen:
    • Gehen Sie zu Directory → Groups und erstellen Sie Gruppen, die den bereits in der nachgelagerten App vorhandenen Gruppen entsprechen
    • Weisen Sie Nutzer diesen IdP-eigenen Gruppen zu
  3. Group Push konfigurieren (für Apps, die dies unterstützen):
    • In der IdP-Konfiguration der App: Registerkarte Push Groups → Gruppen nach Namen suchen → mit vorhandenen nachgelagerten Gruppen verknüpfen
    • Dadurch überschreibt der IdP die app-interne Mitgliedschaft — der IdP wird zur einzigen maßgeblichen Quelle
    • Devin benötigt keinen Group Push, da es Gruppen direkt aus der Anmelde-Assertion ausliest
  4. SCIM-Gruppensynchronisierung in den anderen Apps deaktivieren:
    • Stellen Sie sicher, dass „Import Groups“ deaktiviert bleibt, damit die nachgelagerte App nicht erneut beansprucht, die maßgebliche Quelle zu sein
Für Devin selbst ist keine Migration erforderlich. Stellen Sie einfach sicher, dass die Schritte 1–3 oben durchgeführt wurden (Gruppen in Ihrem IdP definiert, Claims konfiguriert, Zuordnungen in Devin festgelegt).

Wichtige Hinweise

Wenn eine Gruppe umbenannt wird, behandelt Devin sie als neue Gruppe. Die Rollenzuordnungen der alten Gruppe werden nicht automatisch übernommen — Sie müssen den neuen Gruppennamen in den Settings von Devin erneut konfigurieren.
Ein Nutzer, der zu einer Devin-zugeordneten IDP-Gruppe hinzugefügt wird, erhält diesen Zugriff erst nach der Anmeldung.
Wenn ein Nutzer aus einer IDP-Gruppe entfernt wird, wird sein Zugriff auf Devin nicht sofort entzogen. Bei der nächsten Anmeldung synchronisiert Devin die Änderungen und entfernt die veraltete Gruppenzugehörigkeit. Eine direkte Mitgliedschaft (die außerhalb von Gruppen zugewiesen wurde) bleibt davon unberührt.
Der Gruppenname im IdP muss exakt mit dem übereinstimmen, was Devin sieht. Groß- und Kleinschreibung werden beachtet.
Devin unterstützt keine verschachtelten bzw. hierarchischen Gruppen. Wenn der IdP eine übergeordnete Gruppe sendet, werden Mitglieder untergeordneter Gruppen nicht automatisch einbezogen. Jede Gruppe muss ausdrücklich zugewiesen werden.

Für die engstmögliche Kontrolle ohne SCIM folgen Sie diesem Ansatz:
1

Konfigurieren Sie Ihren Identity Provider (maßgebliche Quelle)

  1. Definieren Sie Gruppen: Devin-Admins, Devin-Backend, Devin-Frontend usw.
  2. Weisen Sie Nutzer Gruppen zu
  3. Konfigurieren Sie SAML-/OIDC-Gruppen-Claims, gefiltert nach „Beginnt mit: Devin-
2

Devin synchronisiert bei jeder Anmeldung

Wenn sich ein Nutzer per SSO anmeldet, tut Devin automatisch Folgendes:
  • Erstellt den Nutzer automatisch, wenn er neu ist
  • Führt eine vollständige Gruppensynchronisierung durch (fügt neue Gruppen hinzu und entfernt veraltete)
  • Wendet Gruppen-zu-Rollen- und Gruppen-zu-Org-Zuordnungen sofort an
3

Optional: Mit der V2-API automatisieren

Richten Sie einen geplanten Job ein, um SCIM-Lücken zu schließen:
  1. Rufen Sie aktive Nutzer über Ihre IdP-API ab
  2. Rufen Sie Devin-Mitglieder über GET /v2/enterprise/members ab
  3. Laden Sie neue Mitarbeiter über POST /v2/enterprise/members/invite ein
  4. Entfernen Sie ausgeschiedene Mitarbeiter über DELETE /v2/enterprise/members/{user_id}
So erhalten Sie eine Push-basierte Provisionierung und Deprovisionierung ohne SCIM.

Was Ihnen das bietet

  • Ihr IdP als maßgebliche Quelle für Gruppenstruktur und Mitgliedschaften
  • Automatischer gruppenbasierter Zugriff bei jeder Anmeldung
  • API-gesteuerte Bereitstellung/Deprovisionierung, um die Lücke zu schließen, die SCIM normalerweise abdecken würde
  • Vollständiger Audit-Trail für alle Anmeldungen und Änderungen an Mitgliedschaften

Aktuelle Einschränkungen

  • Echtzeit-Synchronisierung von Gruppen zwischen Anmeldungen — Gruppen werden nur aktualisiert, wenn Nutzer sich anmelden
  • Sofortige Sitzungsbeendigung bei der Deprovisionierung — Sitzungen bleiben aktiv, bis sie ablaufen
  • Vom IdP ausgelöste Lifecycle-Ereignisse wie Suspend/Reactivate werden nicht unterstützt