Freigeben über

Konfigurieren des nicht authentifizierten Anbieters

Der Unauthenticated Anbieter gibt dem Data-API-Builder an, kein JSON-Webtoken (JWT) zu prüfen oder zu validieren. Jede Anforderung wird als die anonymous Rolle ausgeführt. Es gibt keine Ausnahmen innerhalb von DAB.

Hinweis

Die in diesem Abschnitt beschriebene Funktionalität des Daten-API-Generators 2.0 befindet sich derzeit in der Vorschau und kann sich vor der allgemeinen Verfügbarkeit ändern. Weitere Informationen finden Sie unter Neuigkeiten in Version 2.0.

Verwenden Sie diesen Anbieter, wenn DAB jede Anforderung als anonymous behandeln soll, auch wenn ein anderer Dienst vor DAB die Authentifizierung durchführt oder Zugriffsrichtlinien anwendet.

Von Bedeutung

Der Unauthenticated Anbieter wandelt die Upstreamidentität niemals in DAB-Identität um. Wenn Sie DAB zum Überprüfen von Token benötigen, aktivieren Sie die authenticated Rollen, verwenden Sie benutzerdefinierte Rollen oder übergeben Sie Benutzeransprüche an nachgeschaltete Richtlinien, verwenden Sie einen validierenden Anbieter wie EntraId oder Custom, AppService.

Authentifizierungsfluss

Mit dem Unauthenticated Anbieter überspringt DAB die Tokenüberprüfung vollständig und wertet Berechtigungen als anonymous:

Phase Was ist los
Clientanforderung Der Client sendet eine Anforderung an DAB, entweder direkt oder über einen anderen Dienst.
Vorgelagerte Steuerelemente Ein Front-End,-Gateway oder -Proxy kann den Anrufer authentifizieren oder grobkörnigen Zugriff erzwingen, bevor die Anforderung weitergeleitet wird.
Anforderung weiterleiten Die Anforderung erreicht DAB
DAB-Verarbeitung DAB überprüft keine JWTs und behandelt die Anforderung immer als anonymous
Autorisierung DAB wertet Entitätsberechtigungen für die anonymous Rolle aus.

Wann dieser Anbieter verwendet werden soll

Verwenden Sie Unauthenticated in diesen Szenarien:

Szenario Passt gut? Warum?
API-Verwaltung oder Gateway authentifiziert Benutzer zuerst Ja Das Front-End kann den Zugriff steuern, während DAB weiterhin Anforderungen nur für die anonymous-Rolle autorisiert.
Nur interner Dienst hinter einer privaten Netzwerkgrenze Ja Der Netzwerkzugriff wird außerhalb von DAB gesteuert, und DAB kann anonymous-nur bleiben.
Schnelles lokales Setup ohne Konfiguration der JWT-Validierung Ja Einfachste Methode für die ersten Schritte
DAB direkt zugänglich für Browser und öffentliche Clients No DAB überprüft keine Identitätstoken
Sie benötigen authenticated oder eine benutzerdefinierte Rollenaktivierung innerhalb von DAB No Nur anonymous ist bei diesem Anbieter aktiv.

Kurzreferenz

Setting Wert
Provider Unauthenticated
Token erforderlich No
Aktive DAB-Rolle anonymous
Unterstützt JWT-Validierung No
Unterstützt authenticated Rolle No
Unterstützt benutzerdefinierte Rollen No

Schritt 1: Konfigurieren des Anbieters

Legen Sie den Authentifizierungsanbieter auf Unauthenticated.

CLI

dab configure \
  --runtime.host.authentication.provider Unauthenticated

Resultierende Konfiguration

{
  "runtime": {
    "host": {
      "authentication": {
        "provider": "Unauthenticated"
      }
    }
  }
}

Hinweis

Der Unauthenticated Anbieter ist die Standardeinstellung für neue Konfigurationen in DAB 2.0. Beim Ausführen dab init wird eine funktionierende Konfiguration ohne JWT-Einstellungen erstellt.

Schritt 2: Konfigurieren von Entitätsberechtigungen für anonymous

Da DAB alle Anforderungen als anonymous behandelt, müssen Ihre Entitäten Zugriff auf die Rolle für alle Vorgänge gewähren, die Sie zulassen möchten, anonymous.

Beispielkonfiguration

{
  "entities": {
    "Book": {
      "source": "dbo.Books",
      "permissions": [
        {
          "role": "anonymous",
          "actions": ["read"]
        }
      ]
    }
  }
}

Wenn eine Entität nur auf authenticated oder eine benutzerdefinierte Rolle zugreift, schlagen Anforderungen fehl, da diese Rollen nie aktiviert werden, wenn Unauthenticated konfiguriert ist.

Von Bedeutung

Wenn Unauthenticated aktiv ist, werden authenticated und benutzerdefinierte Rollen, die in Entitätsberechtigungen definiert sind, nie aktiviert. Wenn Ihre Konfiguration diese Rollen enthält, gibt DAB beim Start eine Warnung aus.

Schritt 3: Optional einen anderen Dienst vor DAB platzieren

Ein anderer Dienst kann weiterhin Anrufer authentifizieren oder grobkörnige Zugriffsregeln anwenden, bevor die Anforderung DAB erreicht. Das ändert das Verhalten von DAB nicht:

  1. Authentifizieren Sie den Anrufer im Front-End, Gateway oder Proxy.
  2. Wenden Sie dort eine grob abgestufte Zugriffsrichtlinien an.
  3. Weiterleiten genehmigter Anforderungen an DAB.
  4. Verwenden Sie DAB-Entitätsberechtigungen, um zu steuern, was die anonymous Rolle tun kann.

Dieses Muster eignet sich gut, wenn eine umgebende Plattform steuert, wer DAB erreichen kann, während DAB absichtlich nur anonymous bleibt.

Was dieser Anbieter nicht tut

Der Anbieter Unauthenticated erfüllt folgendes nicht:

  • Validieren von Bearer-Token
  • Aktivieren der authenticated Rolle
  • Aktivieren von benutzerdefinierten Rollen aus Claims
  • Bereitstellung von Ansprüchen für Datenbankrichtlinien
  • Durchführen einer benutzerspezifischen Autorisierung innerhalb von DAB

Wenn Sie diese Funktionen benötigen, verwenden Sie einen Anbieter, der Identität für DAB bereitstellt.

Vollständiges Konfigurationsbeispiel

{
  "$schema": "https://github.com/Azure/data-api-builder/releases/latest/download/dab.draft.schema.json",
  "data-source": {
    "database-type": "mssql",
    "connection-string": "@env('SQL_CONNECTION_STRING')"
  },
  "runtime": {
    "host": {
      "authentication": {
        "provider": "Unauthenticated"
      }
    }
  },
  "entities": {
    "Book": {
      "source": "dbo.Books",
      "permissions": [
        {
          "role": "anonymous",
          "actions": ["read"]
        }
      ]
    }
  }
}

Verwandte Inhalte

  • Last updated on