Skip to main content
Die Einstellungen des Enterprise-Workspace geben Admins zentrale Kontrolle darüber, wie Apps und Superagents für alle im Workspace funktionieren. Du kannst SSO für alle Apps erzwingen, Veröffentlichungsrechte und Sichtbarkeitsrichtlinien pro Rolle festlegen und Superagents komplett deaktivieren, wenn sie nicht zu deiner Organisation passen.

​
SSO für den App-Zugriff verwalten

Enterprise-Admins können SSO für alle Apps in einem Workspace über einen einzigen Anbieter erzwingen. Das erleichtert die Anmeldung bei mehreren Apps und sorgt dafür, dass deine Sicherheitsstandards überall gelten. Wenn dein Unternehmen zum Beispiel 10 verschiedene Apps in einem Base44-Workspace hat, meldet sich mit SSO für den App-Zugriff jeder mit den zentralen Firmen-Zugangsdaten an, statt für jede App neue Logins anzulegen.
Wichtig:
  • Nur Enterprise-Admins können SSO für den App-Zugriff verwalten. Nach der Aktivierung nutzen App-Nutzer die SSO-Zugangsdaten deiner Organisation für jede App im Workspace.
  • Um Workspace-SSO für alle Apps zu erzwingen, musst du eine zusätzliche Redirect-URI in der Konfiguration deines Identity Providers (IdP) hinzufügen: https://app.base44.com/api/workspace_apps/{{WORKSPACE_ID}}/auth/sso/callback
So richtest du SSO für alle Apps im Workspace ein:
  1. Richte dein Enterprise-Workspace-SSO ein.
  2. Klicke unten links auf deinen Workspace-Namen.
  3. Klicke auf Settings.
  4. Klicke auf Governance.
  5. Klicke auf den Apps SSO Schalter.
    • Aktiviert: Alle Apps nutzen die Workspace-SSO-Einstellungen und die Konfiguration auf App-Ebene ist deaktiviert. Öffentliche Apps, die vorher keine Anmeldung brauchten, verlangen sie jetzt, sowohl für die App als auch für ihre API.
    • Deaktiviert: Bestehende Apps behalten Workspace-SSO und erfordern weiterhin eine Anmeldung. Nur neue Apps nutzen ihre eigenen Authentifizierungseinstellungen.

​
Zugriff auf private Apps automatisch gewähren

Enterprise-Admins können einen Workspace-Standard festlegen, der Personen automatisch Zugriff auf berechtigte private Apps gibt, wenn sie sich per SSO anmelden. So musst du niemanden mehr zu einzelnen Apps einladen oder Zugriffsanfragen einzeln freigeben. Das gilt nur für private Apps, die SSO als einzige Anmeldemethode nutzen. Personen, die sich anders anmelden, nutzen weiterhin den normalen Ablauf mit Einladung oder Zugriffsanfrage.
Bevor du beginnst: Der Workspace-Standard erfordert den Enterprise plan.
So gewährst du automatisch Zugriff auf private Apps:
  1. Klicke unten links auf deinen Workspace-Namen.
  2. Klicke auf Settings.
  3. Klicke auf Governance.
  4. Suche die Apps SSO Karte.
  5. Klicke auf den Auto-admit SSO users Schalter.
Workspace-Standard für automatische Zulassung von SSO-Nutzern in privaten Apps festlegen

Workspace-Standard für automatische Zulassung von SSO-Nutzern in privaten Apps festlegen

Die Workspace-Einstellung wird zum Standard für berechtigte Apps, und so zugelassene Personen bekommen die Nutzerrolle. Du kannst den Standard für einzelne Apps in den Authentifizierungseinstellungen der App überschreiben. Eine App ohne eigene Einstellung folgt dem Workspace-Standard. Eine App mit eigener Einstellung behält sie, ein oder aus, und spätere Änderungen am Workspace-Standard wirken sich nicht auf sie aus.
Hinweise:
  • Auto-admit gilt nur, solange SSO die einzige Anmeldemethode der App ist. Wenn du eine andere Anmeldemethode hinzufügst oder SSO abschaltest, stoppt Auto-admit für diese App, auch wenn der Workspace-Standard aktiv ist.
  • Das Deaktivieren des Workspace-Standards entfernt niemanden, der bereits Zugriff hat.
  • Wenn du jemanden aus Users in deinem App-Dashboard entfernst, wird der Zugriff nicht widerrufen. Diese Person wird beim nächsten SSO-Login wieder zugelassen. Entferne oder sperre sie stattdessen in deinem Identity Provider.

​
Veröffentlichungsrechte

Mit Veröffentlichungsrechten steuerst du, was jede Rolle (Owner, Admin, Editor und Guest) beim Veröffentlichen von Apps tun darf: ob sie veröffentlichen darf, welche Sichtbarkeitsstufen sie wählen kann und welche standardmäßig gesetzt ist. Wenn die Rolle eines Mitglieds eine Veröffentlichung blockiert, kann es dir stattdessen eine Freigabeanfrage zur Veröffentlichung senden, damit die Arbeit ohne Aufweichen deiner Richtlinien weitergeht.
Hinweise:
  • Die Owner-Rolle hat immer Veröffentlichungsrechte und kann jede Sichtbarkeitsstufe nutzen. Ihre Einstellungen lassen sich nicht ändern.
  • Mitglieder mit einer Rolle ohne Veröffentlichungsrecht können weiterhin Apps bauen und bearbeiten.

​
Veröffentlichungsrechte festlegen

Konfiguriere Veröffentlichungsrechte und Sichtbarkeitsstufen für jede Rolle in deinen Workspace-Einstellungen. So legst du Veröffentlichungsrechte pro Rolle fest:
  1. Klicke unten links auf deinen Workspace-Namen.
  2. Klicke auf Settings.
  3. Klicke auf Governance.
  4. Suche in der Publishing permissions Tabelle die Rolle, die du konfigurieren willst.
  5. Nutze den Can publish Schalter, um Veröffentlichungen für diese Rolle zu erlauben oder zu blockieren.
  6. Wähle unter Allowed visibility die Sichtbarkeitsstufen, die die Rolle nutzen darf. Wähle mindestens eine Stufe:
    • Alle: Die Rolle kann jede Sichtbarkeitsstufe nutzen.
    • Privat: Nur Nutzer, die du ausdrücklich einlädst, haben Zugriff.
    • Workspace: Alle Workspace-Mitglieder haben Zugriff.
    • Öffentlich (Anmeldung erforderlich): Jeder mit einem Base44-Konto hat Zugriff, auch Personen außerhalb deines Workspace.
    • Öffentlich (ohne Anmeldung): Jeder im Internet hat Zugriff. Kein Konto nötig.
  7. Wähle unter Default visibility die Sichtbarkeitsstufe, die automatisch gesetzt wird, wenn jemand mit dieser Rolle veröffentlicht. Du kannst nur aus den im vorherigen Schritt erlaubten Stufen wählen.
Um jede Rolle auf die ursprünglichen Einstellungen zurückzusetzen, klicke auf Reset to defaults.
Für die Governance-Nachverfolgung werden Änderungen an Veröffentlichungsrechten in den Audit-Logs deines Workspace als Governance-Regeländerungen protokolliert, zusammen mit jedem App-Publish-, Unpublish- und Freigabeanfrage-Ereignis. Du kannst diese Ereignisse mit der Audit Logs API abrufen.

​
Freigabeanfragen zur Veröffentlichung

Wenn jemand in deinem Workspace veröffentlichen will, seine Rolle aber keine Berechtigung hat oder die gewählte Sichtbarkeitsstufe für seine Rolle nicht erlaubt ist, kann er statt blockiert zu werden eine Veröffentlichungsanfrage senden. Du und die anderen Workspace-Owner und -Admins werden per E-Mail und in deinen Base44-Benachrichtigungen unter dem Bell Symbol oben in deinem Workspace informiert. Ein Klick auf die Benachrichtigung öffnet die App im Editor, wo einer von euch sie prüfen und im Namen des Mitglieds veröffentlichen kann. Auf der Seite des Mitglieds zeigt das Publish Panel im App-Editor einen Request to publish Button. Er öffnet ein kurzes Anfrageformular, in dem das Mitglied die gewünschte Sichtbarkeit für die App auswählt, optional eine Nachricht für den Prüfer hinzufügt und auf Send request klickt.
Freigabe zur App-Veröffentlichung anfordern

Freigabe zur App-Veröffentlichung anfordern

Jede Anfrage zeigt dir die E-Mail-Adresse des Mitglieds, die angefragte Sichtbarkeit und die Nachricht.

​
MCP-Zugriff für Apps verwalten

Owner und Admins eines Enterprise-Workspace können steuern, ob Apps in ihrem Workspace einen MCP-Server für KI-Assistenten bereitstellen. So verwaltest du den MCP-Zugriff:
  1. Gehe zu den Settings deines Workspace.
  2. Klicke auf Governance.
  3. Suche MCP access for AI assistants.
  4. Wähle eine Richtlinie:
    • Erlaubt: Apps können einen MCP-Server mit oder ohne Anmeldung bereitstellen.
    • Anmeldung erforderlich: Apps können einen MCP-Server bereitstellen, aber KI-Assistenten müssen sich anmelden. Jeder App-MCP-Server im Workspace nutzt OAuth.
    • Nicht erlaubt: Apps im Workspace können keinen MCP-Server bereitstellen.
Richtlinienänderungen gelten ohne erneutes Veröffentlichen der betroffenen Apps. Bei Not allowed werden bestehende MCP-Server bei ihrer nächsten Anfrage gestoppt. Für Anleitungen auf App-Ebene siehe KI-Assistenten mit deiner App verbinden.

​
Superagents verwalten

Du kannst verhindern, dass Workspace-Mitglieder Superagents erstellen, aufrufen oder mit ihnen interagieren. Wenn diese Einstellung aktiv ist, sind Superagents für alle Mitglieder im Workspace ausgeblendet. Das ist hilfreich, wenn deine Organisation KI-Agenten nicht freigegeben hat oder du Superagents schrittweise an bestimmte Teams ausrollen willst.
Nur Workspace-Owner und -Admins können Superagents für den Workspace aktivieren oder deaktivieren.
So deaktivierst du Superagents für deinen Workspace:
  1. Klicke unten links auf deinen Workspace-Namen.
  2. Klicke auf Settings.
  3. Klicke auf Basic information.
  4. Aktiviere den Disable Superagents Schalter.
Disable Superagents toggle in Basic information settings

Superagents für deinen Enterprise-Workspace deaktivieren

​
FAQs

Wähle unten eine Frage, um mehr über App-SSO und Sichtbarkeit zu erfahren.
Bestehende Apps nutzen automatisch deine Workspace-SSO-Einstellungen, wenn die Erzwingung aktiv ist. SSO-Einstellungen auf App-Ebene sind gesperrt und können nur von Enterprise-Admins verwaltet werden.
Nein. Wenn die Workspace-SSO-Erzwingung aktiv ist, nutzen alle Workspace-Apps den SSO-Anbieter des Unternehmens. App-Builder können SSO-Einstellungen nur wählen, wenn die Erzwingung von einem Admin deaktiviert ist.
Ja, du kannst die Sichtbarkeit einer App jederzeit in den App-Einstellungen ändern, sofern die Workspace-Richtlinien es zulassen.
Für Organisationen mit internen und kundenseitigen Apps konfigurierst du deinen Workspace so:Workspace-Ebene:
  • Workspace-SSO: AN (Mitarbeiter nutzen Firmen-Zugangsdaten)
  • Apps SSO Schalter: AUS (nicht global erzwingen)
App-Ebene:
  • Interne Apps: Workspace-SSO einzeln aktivieren
  • Kundenseitige Apps: Eigene Authentifizierung (E-Mail/Passwort, Google) mit passender Sichtbarkeit nutzen
So bleibst du flexibel, schützt interne Tools und hältst Kunden-Apps zugänglich.
Auth-Einstellungen auf App-Ebene werden in den neuen Workspace übernommen. Beachte dabei aber Folgendes:
  1. Wenn in deinem Workspace der Apps SSO Schalter aktiv ist, überschreibt Workspace-SSO sofort alle Auth-Einstellungen auf App-Ebene.
  2. Bestehende App-Nutzer bleiben erhalten. Wenn die App aber vorher eine Anmeldemethode nutzte, die im neuen Workspace nicht konfiguriert ist (etwa ein individuelles SSO mit anderer Redirect-URI), kann es bis zur Neukonfiguration der Auth zu Login-Problemen kommen.
  3. Wenn die App Connectors eingerichtet hat (OAuth-Verbindungen zu Google, Slack usw.), die an die einrichtende Person und nicht an die App gebunden sind, müssen diese Verbindungen im neuen Workspace-Kontext eventuell neu autorisiert werden.
Diese Seite wurde mit KI übersetzt. Für die genauesten und aktuellsten Informationen siehe die englische Version.